ppp/ipcp curiosities

Discussion in 'Linux Networking' started by Hul Tytus, Jul 1, 2014.

  1. Hul Tytus

    Hul Tytus Guest

    comp.os.linux.networking
    ppp/ipcp curiosities

    Does anyone know the purpose of a dial-up service sending their ip address as
    an option in a request? The lines below, starting with the ppp header, show an
    example (in hex) of a sucsessful ipcp exchange with a national US "dial up"
    service. The 40 88 a7 a2 is the services ip address, globalpop.com, if memory
    serves.

    Hul


    ppp send: unadorned 16 byte packet:
    FF 03 80 21 01 01 00 0A 03 06 00 00 00 48 5F E6 1
    ppp recv: unadorned 22 byte packet:
    FF 03 80 21 01 01 00 10 02 06 00 2D 0F 01 03 06 40 88 A7 A2 5B 21 2
    ppp send: unadorned 16 byte packet:
    FF 03 80 21 04 01 00 0A 02 06 00 2D 0F 01 86 DE 3
    ppp recv: unadorned 16 byte packet:
    FF 03 80 21 03 01 00 0A 03 06 48 FB 20 E0 9D E2 4
    ppp send: unadorned 16 byte packet:
    FF 03 80 21 01 02 00 0A 03 06 48 FB 20 E0 D4 6C 5
    ppp recv: unadorned 16 byte packet:
    FF 03 80 21 01 02 00 0A 03 06 40 88 A7 A2 62 46 6
    ppp send: unadorned 16 byte packet:
    FF 03 80 21 02 02 00 0A 03 06 40 88 A7 A2 0B 32 7
    ppp recv: unadorned 16 byte packet:
    FF 03 80 21 02 02 00 0A 03 06 48 FB 20 E0 BD 18 8
     
    Hul Tytus, Jul 1, 2014
    #1
    1. Advertisements

  2. Hul Tytus

    Lew Pitcher Guest

    A cursory read through RFC 1332 (the IPCP RFC) and others suggests that this
    is the accepted way for a link to request that the peer supply the local
    side IP address.

    Specifically, it looks like we are interested in the IP Address
    Configuration option of IPCP, which starts with the 03 06. It reads:
    03 06 40 88 A7 A2
    and breaks out as
    03 - IP-Address Configuration Option
    06 - 6 bytes in option (header + payload)
    40 8B A7 A2 - IP address

    To quote the RFC:
    This Configuration Option provides a way to negotiate the IP
    address to be used on the local end of the link. It allows the
    sender of the Configure-Request to state which IP-address is
    desired, or to request that the peer provide the information. The
    peer can provide this information by NAKing the option, and
    returning a valid IP-address.

    Note the process described:
    1) The local end sends an IP-Address request containing an IP address. I
    2) The peer responds with an ACK or a NAK
    3a) If the response was an ACK, the local end uses that address
    3b) If the response was a NAK, the peer will send a valid IP address to use

    So, the local end has to ask "Can I use this address?", and the peer has to
    say "No, use /this one/ instead."

    It makes sense that, if the local end has to send an IP address, that it use
    an IP address that the peer knows is not available. And thus, it seems
    likely that the ISP might want the local end to ask for the ISP's IP
    address, just to make the request obvious.
     
    Lew Pitcher, Jul 1, 2014
    #2
    1. Advertisements

  3. Hul Tytus

    Hul Tytus Guest

    Nice figuring Lew, thanks. The question of why so many occurrances does
    remain though.

    Hul

     
    Hul Tytus, Jul 1, 2014
    #3
  4. Hul Tytus

    Moe Trin Guest

    On Tue, 01 Jul 2014, in the Usenet newsgroup comp.os.linux.networking, in
    Yup - but there are more options that are included in the IPCP
    negotiations phase, such as VJ header compression, MS-DNS, regular
    DNS and so on, and all has to be negotiated such that at the end of
    the negotiations, each peer knows exactly what it needs to ask for,
    and the other peer then approves that final (all inclusive) request.
    From an old handout I used to quote:

    =======
    Jul 13 09:55:28 gtech pppd[924]: sent [IPCP ConfReq id=0x1 <addr
    0.0.0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0>
    <ms-dns2 0.0.0.0> <ms-wins 0.0.0.0>]

    This box now asks to talk TCP/IPv4 (IPv6 is possible, but is not
    discussed in this note), but doesn't know it's IP address (which is
    normal), asks for two DNS server and two WinDNS servers, but doesn't
    know the addresses of these either (again, normal)

    Jul 13 09:55:30 gtech pppd[924]: rcvd [IPCP ConfRej id=0x1 <ms-wins
    0.0.0.0> <ms-wins 0.0.0.0>]

    The peer comes back as tells us where we can shove that WinDNS crap.

    Jul 13 09:55:28 gtech pppd[924]: sent [IPCP ConfReq id=0x2 <addr
    0.0.0.0> <compress VJ 0f 01> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]

    We take the hint, and retry without asking for that blasphemy.

    Jul 13 09:55:30 gtech pppd[924]: rcvd [IPCP ConfReq id=0x1 <compress
    VJ 0f 01> <addr 192.0.2.2>]
    Jul 13 09:55:30 gtech pppd[924]: sent [IPCP ConfAck id=0x1 <compress
    VJ 0f 01> <addr 192.0.2.2>]

    The peer comes back and asks to talk TCP/IPv4, and wants to use that
    address. This box approves this.

    Jul 13 09:55:30 gtech pppd[924]: rcvd [IPCP ConfNak id=0x2 <addr
    192.0.2.158> <compress VJ 0f 01> <ms-dns1 192.0.2.2> <ms-dns2
    192.0.2.3>]
    Jul 13 09:55:30 gtech pppd[924]: sent [IPCP ConfReq id=0x3 <addr
    192.0.2.158> <compress VJ 0f 01> <ms-dns1 192.0.2.2> <ms-dns2
    192.0.2.3>]

    The peer comes back and says that you can't use the addresses 0.0.0.0,
    and suggests asking to use these addresses (ConfNak = "no but"). This
    box takes the hint and does so.

    Jul 13 09:55:30 gtech pppd[924]: rcvd [IPCP ConfAck id=0x3 <addr
    192.0.2.158> <compress VJ 0f 01> <ms-dns1 192.0.2.2> <ms-dns2
    192.0.2.3>]
    Jul 13 09:55:30 gtech pppd[924]: local IP address 192.0.2.158
    Jul 13 09:55:30 gtech pppd[924]: remote IP address 192.0.2.2
    Jul 13 09:55:30 gtech pppd[924]: ms-dns1 192.0.2.2
    Jul 13 09:55:30 gtech pppd[924]: ms-dns1 192.0.2.3

    The peer approves our use of these addressees, and the ppp link is now
    up and running.

    =======

    Lots of "mother, may I" and "no, but try asking for" back and forth
    before we cab get to a final "ConfAcq" in both directions. This data
    was obtained by adding 'debug' or '-d' to the ANU ppp command, and
    having the logging daemon capture "daemon.debug" output and send that
    to some file.
    The response is more in the line of "no, but try asking for /this one/"
    because neither peer can impose on the other - they can only suggest,
    and finally approve one set of things all at once. You can't approve
    IP addresses, then later try to negotiate IPCP again to get header
    compression or DNS addresses, etc.
    ..
    Old guy
     
    Moe Trin, Jul 2, 2014
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.