In article <TfKXc.351$wK3.26@read3.inet.fi>, Tauno Voipio wrote:
>The route command is stubborn:
> - to add a network route, the mask must be != 255.255.255.255
> - you probably would like to have the gateway as 255.255.255.255
>
>How about this:
>
> route add -net 192.168.20.0 netmask 255.255.255.0 gw 255.255.255.255

See up-thread. That was accepted by my system running a 2.0.40 kernel,
but the networking results were not as desired.

><rant>
>
>A PPP with a reserved point address is sick.
>
></rant>

You won't get a disagreement from us, but remember that many ISPs do not
want anyone logging in (or otherwise trying to connect) to their terminal
servers _EXCEPT_ to use it as a gateway. As such, they really could use
nearly anything they wanted as an address because the address does not
_normally_ appear in an IP packet - including something really bizarre
like 1.0.0.0 - which CAN be used as a host address as long as it doesn't
get out past the perimeter. Yes, IANA wants you to use RFC1918, but...

>Regards from Helsinki, the home city of Linux.

ITYM "Birth City". Last I knew, Linus was goofing off in Cupertino, CA.us ;-)

Old guy

Tauno Voipio <tauno.voipio@iki.fi.nospam.invalid> wrote:

> How about this:

> route add -net 192.168.20.0 netmask 255.255.255.0 gw 255.255.255.255

> Now, the gateway is a host address, which already has routing via eth0.

That doesn't work for the 2.6.7 kernel either:

~# route add -net 192.168.20.0 netmask 255.255.255.0 gw 255.255.255.255 eth0
SIOCADDRT: Network is unreachable

The result is the same regardless of whether a 255.255.255.255 host route
exists or not. That is, it doesn't work when the initial routing is

192.168.1.0 * 255.255.255.0 U 0 0 0 eth0

or when the initial routing is

255.255.255.255 * 255.255.255.255 UH 0 0 0 eth0
192.168.1.0 * 255.255.255.0 U 0 0 0 eth0

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

Clifford Kite wrote:
> Tauno Voipio <tauno.voipio@iki.fi.nospam.invalid> wrote:
>
>
>>How about this:
>
>
>> route add -net 192.168.20.0 netmask 255.255.255.0 gw 255.255.255.255
>
>
>>Now, the gateway is a host address, which already has routing via eth0.
>
>
> That doesn't work for the 2.6.7 kernel either:
>
> ~# route add -net 192.168.20.0 netmask 255.255.255.0 gw 255.255.255.255 eth0
> SIOCADDRT: Network is unreachable
>
> The result is the same regardless of whether a 255.255.255.255 host route
> exists or not. That is, it doesn't work when the initial routing is
>
> 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
>
> or when the initial routing is
>
> 255.255.255.255 * 255.255.255.255 UH 0 0 0 eth0
> 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0
>

I just wonder if the target address is the broadcast address
to get rid of ARP associated with a normal local network packet
transfer. The trick has a strong scent of a dirty hack. A
standard-compliant stack should not accept it.

Is the Ethernet connection a point-to-point connection
without any other hosts in the same segment?

Maybe the correct solution is a new driver a la PPPoE using
raw sockets to transfer the data.

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio <tauno.voipio@iki.fi.nospam.invalid> wrote:

> I just wonder if the target address is the broadcast address
> to get rid of ARP associated with a normal local network packet
> transfer. The trick has a strong scent of a dirty hack. A
> standard-compliant stack should not accept it.

Agreed, on both counts.

> Is the Ethernet connection a point-to-point connection
> without any other hosts in the same segment?

My ethernet card is not connected to any host. I did have another host
connected with a cross-over cable but it died and hasn't been replaced.

That might be the reason for the "SIOCADDRT: Network is unreachable"
in this case - I just don't know enough to say yea or nay. While I
seem to still be able to configure network-gateway routing for most any
ordinary network and gateway address without another host, "limited
broadcast" may be different.

> Maybe the correct solution is a new driver a la PPPoE using
> raw sockets to transfer the data.

That's way out of my league. I just supposed that something like PPPoE
(PPP over Wireless?) was being used.

As far as a hack to pppd goes I can only speculate wildly. It might be
possible to intercept the 255.255.255.255 in the part of pppd/auth.c
with the IN_BADCLASS(addr) test and substitute a non-local private IP
address so that pppd believes the IPCP negotiations are successful and
will use that IP address as the remote's. I have no clue as to whether
such a hack would work.

But for my POTS PPP link I can (optionally) specify a private IP address
for the remote IP address, it is cheerfully accepted by the ISP host,
the PPP interface is brought up with that remote IP address, and the
link is viable.

-- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* Emacs vs vi:
Sort of like a Swiss Army knife versus a rapier. */

In article <2jh2hc.p03.ln@corncob.localhost.tld>, Clifford Kite wrote:
>Tauno Voipio <tauno.voipio@iki.fi.nospam.invalid> wrote:
>
>> The trick has a strong scent of a dirty hack. A
>> standard-compliant stack should not accept it.
>
>Agreed, on both counts.

Absolutely. Like I said - I wonder what the heck AT&T was thinking
when they decided to use that address.

>My ethernet card is not connected to any host.

Technically, it shouldn't matter, as long as the card can be configured.
I've seen cards that were (literally) burnt up through misapplication of
a power line to the network connector, yet the card came up, and was
happily pinging itself according to the user. In fact, the loopback was
routing those pings - but the card was considered to be up and working.
It just smelled kinda funny. (No, I dihdn't ask - I was having a hard
enough time trying not to laugh while listening to the user's statement.)

>That might be the reason for the "SIOCADDRT: Network is unreachable"
>in this case - I just don't know enough to say yea or nay.

If I recall correctly, you _were_ able to set up a host route
to 255.255.255.255, right? I believe the error message is a result of
a sanity check in the networking code.

>As far as a hack to pppd goes I can only speculate wildly. It might be
>possible to intercept the 255.255.255.255 in the part of pppd/auth.c
>with the IN_BADCLASS(addr) test and substitute a non-local private IP
>address

or even the only slightly less bizarre address 255.255.255.254

>so that pppd believes the IPCP negotiations are successful and will use
>that IP address as the remote's. I have no clue as to whether such a
>hack would work.

Speculation on my part too, but I think it should work as long as the
peer doesn't object (and that may be hacked around too). The reason
being that the peer's IP address rarely has to be used over the wire.
When you send an IP packet, the destination address is that of the
ultimate destination, not that of the intermediate routers. The peer's
(or intermediate router's) address only is found at the media or link
level protocol. I could be wrong (reading Stevens 1 section 2.6), but
I don't see any functional address actually _used_ at the ppp layer.
The "address"is always 0xff. Thus, the only time you might have to
talk to the peer is when the ISP has it running a DNS or mail server
or similar. Of course, I don't know how the resolver code or a mail
tool might feel about the server being on 255.255.255.255, but that's
not what we're talking about here.

Old guy