Re: AT&T Wireless GPRS networking with Merlin G100 card
From: Clifford Kite (kite_at_see.signature.id)
Date: Wed, 25 Aug 2004 00:11:35 -0500
Moe Trin <firstname.lastname@example.org> wrote:
> In article <email@example.com>, Clifford Kite wrote:
> Like you, I'm not a C programmer, but wonder what the kernel would think
> on finding 255.255.255.255 listed as the next hop. That address is an
> acceptable destination, because it's used all the time by BOOTP and DHCP,
> but technically, it can't be a host address based on RFC1122. Still, we
> all have seen systems that don't exactly follow the rules.
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.
>>And I'm out of suggestions - except for modifying pppd.
> I ran out a while ago.
>>I suspect, but do not *know*, that removing "|| IN_MULTICAST(addr) "
>>from this code in pppd/auth.c will let pppd accept 255.255.255.255
>>when it's requested by the remote:
> Hmmm, is it that, or IN_BADCLASS(addr) ? I can _sorta_ see what you
Here are the results of greping /usr/include for IN_MULTICAST, IN_CLASSD,
and IN_BADCLASS (modified to 76 columns and irrelevant outputs discarded):
#define IN_MULTICAST(a) IN_CLASSD(a)
#define IN_CLASSD(a) ((((in_addr_t)(a)) & 0xf0000000) == 0xe0000000)
#define IN_BADCLASS(a) ((((in_addr_t)(a)) & 0xf0000000) == 0xf0000000)
In order for bad_ip_adrs(addr) to return 1, either IN_MULTICAST(addr) or
IN_BADCLASS(addr) must be true. In light of the above, IN_BADCLASS(addr)
is true for addr ffffffff and IN_MULTICAST (aka IN_CLASSD(addr)) is not.
So you're right, it *is* IN_BADCLASS(addr) that causes pppd to terminate.
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. Backtracking
from the code generating the "Unauthorized" message to find bad_ip_adrs()
wasn't easy for me, and the kernel is a whole new ballgame. I'm not at
all prepared to tackle that.
BTW, it's nice to have someone who has been involved with IT as well as
networking protocols since the 80's posting answers here. Your comments
were insightful, especially as to the cloudy beginnings of "broadcast"
related terms. In time I'll look into the RFCs you mentioned.
-- Clifford Kite Email: "echo firstname.lastname@example.org|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 */