In article <727hgc.67c.ln@corncob.localhost.tld>, Clifford Kite wrote:
> Some testing here leads me to believe that the kernel will not permit
> 255.255.255.255 to be used as the remote IP address for the PPP interface,
> period. I can't reassign it as the remote IP address on an existing PPP
> interface although I can reassign a normal IP address. That seems like
> a good reason for the pppd "Unauthorized" message and link termination.
I also came to the same conclusion. Seems very stupid of AT&T
Wireless to have done that. Now how can we get them to change their
policies to follow current RFCs? Or does anyone have any clues (I am
still open for help here.) On how one could allow that address?
Because of their failure to follow the standards.... They lost a gprs
customer. Seems they are only good for Cell phone service due to their
muffed up system.

--
From the Desk of the Sysop of:
Planet Maca's Opus, a Free open BBS system.
Telephone 860-738-7176 300-33.6kbps Telnet://pinkrose.net.dhis.org
The New Cnews maintainer
B'ichela

In article <727hgc.67c.ln@corncob.localhost.tld>, Clifford Kite wrote:

Hi Clifford.

>Some testing here leads me to believe that the kernel will not permit
>255.255.255.255 to be used as the remote IP address for the PPP interface,
>period.

That's interesting - what mask was being used? Reason I ask is that
the kernel will tolerate 255.255.255.255 when used with DHCP or BOOTP.
Just for jollies, I just tried adding a host route on my ethernet to
255.255.255.255, and then a network route to na-na.land using that
"host" as the gateway.

[compton ~]$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
255.255.255.255 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 52521 eth0
192.168.20.0 255.255.255.255 255.255.255.0 UG 0 0 0 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 3 lo
[compton ~]$

But when I try a 'ping -c1' to either 255.255.255.255 OR 192.168.20.1,
I notice there is no ARP request, and the arp cache remains empty.

[compton ~]# /usr/sbin/tcpdump -i eth0
tcpdump: listening on eth0
15:25:26.940000 atlantis.phx.az.us > 200.200.0.1: icmp: echo request
15:25:54.920000 atlantis.phx.az.us > 255.255.255.255: icmp: echo request
15:26:41.640000 atlantis.phx.az.us > 255.255.255.255: icmp: echo request

[compton ~]$ /sbin/arp -a | grep -v 192.168.1
[compton ~]$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
255.255.255.255 0.0.0.0 255.255.255.255 UH 0 0 3 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 52521 eth0
192.168.20.0 255.255.255.255 255.255.255.0 UG 0 0 3 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 3 lo
[compton ~]$

Note that the Use count increases on eth0, not lo, so the kernel _thinks_
it's sending out the right hose. This is a (don't laugh) 2.0.40 kernel.

Ahh, went to another box, running something ancient, downed the eth0, and
then brought it back up as 255.255.255.255 on 255.0.0.0/8, and added a
host route back to here. That works, and I now see ARP requests from that
box (but not this) and arp replies from here, but nothing in the arp cache.
When I try to ping 192.168.20.1, it's not arping, but is still trying to
send direct. I _think_ this is confusion on the kernel network stack
caused by the "illegal" host address of 255.255.255.255.

>I can't reassign it as the remote IP address on an existing PPP
>interface although I can reassign a normal IP address. That seems like
>a good reason for the pppd "Unauthorized" message and link termination.

I wonder if there is something else being trapped. Grepping for
255.255.255.255 in the ppp-2.4.2 source only turns up hits in pppd/ipcp.c
and sys-linux.c, and both seem to refer to the netmask. There's also two
hits in pppd/plugins/radius/radiusclient/login.radius/migs/login.radius
but I don't think they're relevant.

>But if the kernel won't configure the PPP interface with 255.255.255.255
>as the remote IP address then just changing pppd won't work.

But I wonder which is the cause there - the kernel certainly will allow
a 255.255.255.255 host route (and appearently as a getway much to my
surprise) when done manually with the '/sbin/route' command. I wonder if
pppd is incapable of asking for that.

Hmmm, now how do I get these hosts back to the right configuration ;-)

Old guy

On Wed, 25 Aug 2004 23:01:14 +0000, B'ichela wrote:

> In article <727hgc.67c.ln@corncob.localhost.tld>, Clifford Kite wrote:
>> Some testing here leads me to believe that the kernel will not permit
>> 255.255.255.255 to be used as the remote IP address for the PPP interface,
>> period. I can't reassign it as the remote IP address on an existing PPP
>> interface although I can reassign a normal IP address. That seems like
>> a good reason for the pppd "Unauthorized" message and link termination.
> I also came to the same conclusion. Seems very stupid of AT&T
> Wireless to have done that. Now how can we get them to change their
> policies to follow current RFCs? Or does anyone have any clues (I am
> still open for help here.) On how one could allow that address?
> Because of their failure to follow the standards.... They lost a gprs
> customer. Seems they are only good for Cell phone service due to their
> muffed up system.

Just a data point -- AT & T isn't in the wireless business. When they sold
it 5-6 years ago they also sold the right to use the name "AT & T Wireless"
for some period. Now that Cingular (aka SBC) has bought AT & T Wireless,
expect whatever level of service AT & T Wireless had to drop.

--

Quidquid latine dictum sit, altum viditur.

Moe Trin <ibuprofin@painkiller.example.tld> wrote:
> In article <727hgc.67c.ln@corncob.localhost.tld>, Clifford Kite wrote:

>>But if the kernel won't configure the PPP interface with 255.255.255.255
>>as the remote IP address then just changing pppd won't work.

> But I wonder which is the cause there - the kernel certainly will allow
> a 255.255.255.255 host route (and appearently as a getway much to my
> surprise) when done manually with the '/sbin/route' command. I wonder if
> pppd is incapable of asking for that.

Maybe I'm doing something wrong, or because I'm running a 2.6.7 kernel,
but while I can add a 255.255.255.255 host route on eth0, I cannot
configure the network route with it as the gateway as you did.

This is the routing after adding the host route:
~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
255.255.255.255 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 dummy0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

But

~# route -net 192.168.20.0 gw 255.255.255.255 eth0
Usage: route [-nNvee] [-FC] [<AF>] List kernel routing tables
route [-v] [-FC] {add|del|flush} ... Modify routing table for AF.
....

and the routing is unchanged.

Also if I take eth0 down, remove and reinsert the module to make sure
it's really gone, then

~# ifconfig eth0 255.255.255.255 up
SIOCSIFADDR: Invalid argument
~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:20:AF:1B:5C:48
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:10 Base address:0x280

The eth0 interface is up but with no IP address.

It's likely our results differ because we use different kernels, barring
some gross mistake on my part.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The wealth of a nation is created by the productive labor of its
* citizens. */

Clifford Kite wrote:
> Moe Trin <ibuprofin@painkiller.example.tld> wrote:
>
>>In article <727hgc.67c.ln@corncob.localhost.tld>, Clifford Kite wrote:
>
>
>>>But if the kernel won't configure the PPP interface with 255.255.255.255
>>>as the remote IP address then just changing pppd won't work.
>
>
>>But I wonder which is the cause there - the kernel certainly will allow
>>a 255.255.255.255 host route (and appearently as a getway much to my
>>surprise) when done manually with the '/sbin/route' command. I wonder if
>>pppd is incapable of asking for that.
>
>
> Maybe I'm doing something wrong, or because I'm running a 2.6.7 kernel,
> but while I can add a 255.255.255.255 host route on eth0, I cannot
> configure the network route with it as the gateway as you did.
>
> This is the routing after adding the host route:
> ~# route -n
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 255.255.255.255 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 dummy0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
>
> But
>
> ~# route -net 192.168.20.0 gw 255.255.255.255 eth0
> Usage: route [-nNvee] [-FC] [<AF>] List kernel routing tables
> route [-v] [-FC] {add|del|flush} ... Modify routing table for AF.
> ...
>
> and the routing is unchanged.
>
> Also if I take eth0 down, remove and reinsert the module to make sure
> it's really gone, then
>
> ~# ifconfig eth0 255.255.255.255 up
> SIOCSIFADDR: Invalid argument
> ~# ifconfig
> eth0 Link encap:Ethernet HWaddr 00:20:AF:1B:5C:48
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
> Interrupt:10 Base address:0x280
>
> The eth0 interface is up but with no IP address.
>
> It's likely our results differ because we use different kernels, barring
> some gross mistake on my part.
>

Of course the routing table is unchanged if you enter the route command without
the action parameter.

Maybe you could try "route add ..." ?

Geert

Gerard H. Pille <ghp@skynet.be> wrote:

> Of course the routing table is unchanged if you enter the route
> command without the action parameter.

> Maybe you could try "route add ..." ?

Yes, I did forget to use add, but even so using it results in

~# route add -net 192.168.20.0 gw 255.255.255.255 eth0
SIOCADDRT: Invalid argument

~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
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
192.168.0.0 * 255.255.255.0 U 0 0 0 dummy0
loopback * 255.0.0.0 U 0 0 0 lo

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

Clifford Kite wrote:
> Gerard H. Pille <ghp@skynet.be> wrote:
>
>
>>Of course the routing table is unchanged if you enter the route
>>command without the action parameter.
>
>
>>Maybe you could try "route add ..." ?
>
>
> Yes, I did forget to use add, but even so using it results in
>
> ~# route add -net 192.168.20.0 gw 255.255.255.255 eth0
> SIOCADDRT: Invalid argument
>
> ~# route
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 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
> 192.168.0.0 * 255.255.255.0 U 0 0 0 dummy0
> loopback * 255.0.0.0 U 0 0 0 lo
>

The mask 255.255.255.255 is a host mask. As an address it is the
broadcast address which cannot be a gateway.

You might mean:

route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.1.1 eth0

Your command is not clear on the correct gateway - set it up properly.

HTH

Tauno Voipio
tauno voipio (at) iki fi

Tauno Voipio <tauno.voipio@iki.fi.nospam.invalid> wrote:
> Clifford Kite wrote:
>>
>> ~# route add -net 192.168.20.0 gw 255.255.255.255 eth0
>> SIOCADDRT: Invalid argument
>>
>> ~# route
>> Kernel IP routing table
>> Destination Gateway Genmask Flags Metric Ref Use Iface
>> 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
>> 192.168.0.0 * 255.255.255.0 U 0 0 0 dummy0
>> loopback * 255.0.0.0 U 0 0 0 lo
>>

> The mask 255.255.255.255 is a host mask. As an address it is the
> broadcast address which cannot be a gateway.

> You might mean:

> route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.1.1 eth0

> Your command is not clear on the correct gateway - set it up properly.

I don't doubt that it isn't possible with current kernels. But this thread
started with a GPRS service that insists on pppd accepting 255.255.255.255
as the remote IP address, which pppd refused to do. According to Moe Trin
it is possible to set the route manually under a 2.0.40 kernel.

I respect your knowledge, but you should read through the thread to see
what led up to this point.

-- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/
/* The signal-to-noise ratio is too low in many [news] groups to make
* them good candidates for archiving.
* --- Mike Moraes, Answers to FAQs about Usenet */

Clifford Kite wrote:
> Tauno Voipio <tauno.voipio@iki.fi.nospam.invalid> wrote:
>
>
>> route add -net 192.168.20.0 netmask 255.255.255.0 gw 192.168.1.1 eth0
>
>
>>Your command is not clear on the correct gateway - set it up properly.
>
>
> I don't doubt that it isn't possible with current kernels. But this thread
> started with a GPRS service that insists on pppd accepting 255.255.255.255
> as the remote IP address, which pppd refused to do. According to Moe Trin
> it is possible to set the route manually under a 2.0.40 kernel.
>
> I respect your knowledge, but you should read through the thread to see
> what led up to this point.

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

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

<rant>

A PPP with a reserved point address is sick.

</rant>

Regards from Helsinki, the home city of Linux.

Tauno Voipio
tauno voipio (at) iki fi

In article <v10lgc.jni.ln@corncob.localhost.tld>, Clifford Kite wrote:
>Maybe I'm doing something wrong, or because I'm running a 2.6.7 kernel,
>but while I can add a 255.255.255.255 host route on eth0, I cannot
>configure the network route with it as the gateway as you did.

Yes, I expect this is sanity finally prevailing. For what it's worth,
I checked 2.4.26 and 2.6.6 systems, and they wouldn't take the gateway
either.

>Also if I take eth0 down, remove and reinsert the module to make sure
>it's really gone, then
>
>~# ifconfig eth0 255.255.255.255 up
>SIOCSIFADDR: Invalid argument

I had no trouble with this - but I did specify the netmask. 255.255.255.255
isn't commonly used as an address, and ifconfig may not know how to figure
things out for defaults.

Old guy