PPP problems with GPRS (peer wants 127.0.0.2) - PPP

This is a discussion on PPP problems with GPRS (peer wants 127.0.0.2) - PPP ; Hi, I have an edge/gprs card I'm working on getting working w/ my powerbook and OS 10.3. I have the chat, and most of the ppp part working, but I've hit a problem: - with the "stock" pppd, it fails ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: PPP problems with GPRS (peer wants 127.0.0.2)

  1. PPP problems with GPRS (peer wants 127.0.0.2)

    Hi,

    I have an edge/gprs card I'm working on getting working w/ my powerbook
    and OS 10.3. I have the chat, and most of the ppp part working, but
    I've hit a problem:

    - with the "stock" pppd, it fails after the remote side asks for
    an addr of 127.0.0.2 (odd, but it seems somewhat common in ppp
    implementations)

    Getting the Darwin ppp src, I see why:

    from Helpers/pppd/auth.c:

    /*
    * bad_ip_adrs - return 1 if the IP address is one we don't want
    * to use, such as an address in the loopback net or a multicast address.
    * addr is in network byte order.
    */
    int
    bad_ip_adrs(addr)
    u_int32_t addr;
    {
    addr = ntohl(addr);
    return (addr >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET
    || IN_MULTICAST(addr) || IN_BADCLASS(addr);
    }


    So, I hack that check for loopback out, and re-build pppd. Now, when
    I use that pppd (and chat, no longer using the MacOSX dial/networking
    setup tools), ppp finishes, and brings up the interface. I get
    a 10.x.x.x addr, and my peer gets 127.0.0.2. The routing table
    looks good, but I can't ping anything (127.0.0.2, the dns servers, etc)

    So, now I don't know what to do. Before I dig into the kernel src,
    is there some reason this won't work? Is the peer asking for a 127
    addr ok? Any ideas at all?

    -Seth

  2. Re: PPP problems with GPRS (peer wants 127.0.0.2)

    sjh@scotch.ics.uci.edu (Seth Hettich) writes:
    > - with the "stock" pppd, it fails after the remote side asks for
    > an addr of 127.0.0.2 (odd, but it seems somewhat common in ppp
    > implementations)


    That's just absurd.

    > /*
    > * bad_ip_adrs - return 1 if the IP address is one we don't want
    > * to use, such as an address in the loopback net or a multicast address.
    > * addr is in network byte order.
    > */


    Right. There's no point in allowing the peer to negotiate known bogus
    addresses.

    > So, I hack that check for loopback out, and re-build pppd. Now, when
    > I use that pppd (and chat, no longer using the MacOSX dial/networking
    > setup tools), ppp finishes, and brings up the interface. I get
    > a 10.x.x.x addr, and my peer gets 127.0.0.2. The routing table
    > looks good, but I can't ping anything (127.0.0.2, the dns servers, etc)


    Not surprising. The 127.* network is special, and is reserved for
    loopback only. A great amount of code (somewhat unfortunately)
    depends on that property. They should not be using that for their
    address.

    You might be able to hack ipcp.c so that it negotiates IPCP with any
    wacky address that the peer likes, and then in ipcp_up(), just replace
    that address with something sensible:

    /* peer is an idiot */
    ho->hisaddr = htonl(0x0a000001);

    > So, now I don't know what to do. Before I dig into the kernel src,
    > is there some reason this won't work? Is the peer asking for a 127
    > addr ok? Any ideas at all?


    No, it's not ok. The designer of that peer device is lost in
    confusion.

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  3. Re: PPP problems with GPRS (peer wants 127.0.0.2)

    sjh@scotch.ics.uci.edu (Seth Hettich) writes:

    ]Hi,

    ]I have an edge/gprs card I'm working on getting working w/ my powerbook
    ]and OS 10.3. I have the chat, and most of the ppp part working, but
    ]I've hit a problem:

    ]- with the "stock" pppd, it fails after the remote side asks for
    ]an addr of 127.0.0.2 (odd, but it seems somewhat common in ppp
    ]implementations)

    ]Getting the Darwin ppp src, I see why:

    ]from Helpers/pppd/auth.c:

    ]/*
    ] * bad_ip_adrs - return 1 if the IP address is one we don't want
    ] * to use, such as an address in the loopback net or a multicast address.
    ] * addr is in network byte order.
    ] */
    ]int
    ]bad_ip_adrs(addr)
    ] u_int32_t addr;
    ]{
    ] addr = ntohl(addr);
    ] return (addr >> IN_CLASSA_NSHIFT) == IN_LOOPBACKNET
    ] || IN_MULTICAST(addr) || IN_BADCLASS(addr);
    ]}


    ]So, I hack that check for loopback out, and re-build pppd. Now, when
    ]I use that pppd (and chat, no longer using the MacOSX dial/networking
    ]setup tools), ppp finishes, and brings up the interface. I get
    ]a 10.x.x.x addr, and my peer gets 127.0.0.2. The routing table
    ]looks good, but I can't ping anything (127.0.0.2, the dns servers, etc)

    ]So, now I don't know what to do. Before I dig into the kernel src,
    ]is there some reason this won't work? Is the peer asking for a 127
    ]addr ok? Any ideas at all?

    No the peer getting a 127 address is not ok. That ppp inplimentation is
    broken. Sheesh. The world is full of amatuers making mony off of
    companies by what could only be characterised as fraud writing such
    software.

    Note that 127.0.0.0 is usually routed to the loopback (ie the whole
    subnet) You could try putting in an explicit route to 127.0.0.2 into
    your routing tables and see if that helps.
    Anyway look at your routing tables after ppp comes up.



  4. Re: PPP problems with GPRS (peer wants 127.0.0.2)

    unruh@string.physics.ubc.ca (Bill Unruh) wrote in message news:...

    > No the peer getting a 127 address is not ok. That ppp inplimentation is
    > broken. Sheesh. The world is full of amatuers making mony off of
    > companies by what could only be characterised as fraud writing such
    > software.
    >
    > Note that 127.0.0.0 is usually routed to the loopback (ie the whole
    > subnet) You could try putting in an explicit route to 127.0.0.2 into
    > your routing tables and see if that helps.
    > Anyway look at your routing tables after ppp comes up.


    (the UCI news server seem to be broken, so I'll use Google)

    So, I went ahead and changed the peer addr to something more resonable with
    ifconfig (and then fixed up the route table) and it's working now.

    -Seth

  5. Re: PPP problems with GPRS (peer wants 127.0.0.2)

    James Carlson wrote in message news:...

    > You might be able to hack ipcp.c so that it negotiates IPCP with any
    > wacky address that the peer likes, and then in ipcp_up(), just replace
    > that address with something sensible:
    >
    > /* peer is an idiot */
    > ho->hisaddr = htonl(0x0a000001);


    Do you think that would be a good general solution (I think not, I could be
    using 10.x for something else...). Is there any good general solution to
    this?


    > > So, now I don't know what to do. Before I dig into the kernel src,
    > > is there some reason this won't work? Is the peer asking for a 127
    > > addr ok? Any ideas at all?

    >
    > No, it's not ok. The designer of that peer device is lost in
    > confusion.


    (the UCI news server seem to be broken, so I'll use Google)

    That's what I thought. But, one would hope that AT&T could afford to hire
    someone who knows what they are doing...

    -Seth

  6. Re: PPP problems with GPRS (peer wants 127.0.0.2)

    sjh@zorak.net (Seth Hettich) writes:

    ]James Carlson wrote in message news:...

    ]> You might be able to hack ipcp.c so that it negotiates IPCP with any
    ]> wacky address that the peer likes, and then in ipcp_up(), just replace
    ]> that address with something sensible:
    ]>
    ]> /* peer is an idiot */
    ]> ho->hisaddr = htonl(0x0a000001);

    ]Do you think that would be a good general solution (I think not, I could be
    ]using 10.x for something else...). Is there any good general solution to
    ]this?

    No of course not. The good general solution is not to allow stupid
    addresses. If you for your particular purpose want to allow some stupid
    address from the other side, then hack it in the above way.
    There is no good general solution to handling some peer that violates
    all of the standards.


    ]> > So, now I don't know what to do. Before I dig into the kernel src,
    ]> > is there some reason this won't work? Is the peer asking for a 127
    ]> > addr ok? Any ideas at all?
    ]>
    ]> No, it's not ok. The designer of that peer device is lost in
    ]> confusion.


    ]That's what I thought. But, one would hope that AT&T could afford to hire
    ]someone who knows what they are doing...

    One's hopes are sometimes disappointed.


    ]-Seth

  7. Re: PPP problems with GPRS (peer wants 127.0.0.2)

    sjh@zorak.net (Seth Hettich) writes:
    > > You might be able to hack ipcp.c so that it negotiates IPCP with any
    > > wacky address that the peer likes, and then in ipcp_up(), just replace
    > > that address with something sensible:
    > >
    > > /* peer is an idiot */
    > > ho->hisaddr = htonl(0x0a000001);

    >
    > Do you think that would be a good general solution (I think not, I could be
    > using 10.x for something else...). Is there any good general solution to
    > this?


    A more general solution would be to add a new option to pppd:

    use-remote
    After negotiating IPCP, use the specified address
    (rather than the negotiated remote address) to
    configure the IP interface. This option can be
    helpful if the remote system negotiates a foolish
    address. (As a side-effect, this option disables
    pppd's automatic rejection of illegal IP addresses.)

    All that would matter, though, for the hack I suggested is whether
    10.0.0.1 (that single IP address) is in use on your own network. I
    suspect not, as you're probably trying to use this link to connect to
    the global Internet, and 10.0.0.1 isn't routable on the global
    Internet.

    The peer's remote address is a rather uninteresting factoid for most
    networks. If you were peering with that node using a routing
    protocol, you might care, but that's almost never the case if you're a
    dial-up Internet user.

    > > > So, now I don't know what to do. Before I dig into the kernel src,
    > > > is there some reason this won't work? Is the peer asking for a 127
    > > > addr ok? Any ideas at all?

    > >
    > > No, it's not ok. The designer of that peer device is lost in
    > > confusion.

    >
    > (the UCI news server seem to be broken, so I'll use Google)
    >
    > That's what I thought. But, one would hope that AT&T could afford to hire
    > someone who knows what they are doing...


    I think the situation is rather more complicated than that, but,
    otherwise, "no comment." :-/

    --
    James Carlson, IP Systems Group
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

+ Reply to Thread