remote IP address not being sent - PPP

This is a discussion on remote IP address not being sent - PPP ; I/m trying to debug some software that uses a PPP client in an embedded device. The ISP PPP server that it connects to never sends a configuration-request with an IP-address field, so the client never learns the remote IP address. ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: remote IP address not being sent

  1. remote IP address not being sent

    I/m trying to debug some software that uses a PPP client in an embedded
    device. The ISP PPP server that it connects to never sends a
    configuration-request with an IP-address field, so the client never
    learns the remote IP address.

    When I connect from a WinXP PC using the Microsoft supplied PPP client
    the ISP does send a configuration-request with an IP-address field.

    Anyone know what would cause this?

    This is the PPP sequence, Note that SENDING is from the Clients
    perspective.

    SENDING
    C0 21
    01 01 CONF_REQ #1
    00 18
    08 02
    07 02
    05 06 0E B9 2D A9
    02 06 00 00 00 00
    01 04 05 DC

    RECEIVED
    C0 21
    01 01 CONF_REQ #1
    00 1C
    01 04 05 DC max
    02 06 00 0A 00 00
    03 04 C0 23 authen
    05 06 3C 5E 8D DD magic
    07 02 comp
    08 02 comp
    6E B0

    SENDING
    C0 21
    02 01 ACK #1
    00 1C
    01 04 05 DC
    02 06 00 0A 00 00 COMP IP
    03 04 C0 23
    05 06 3C 5E 8D DD
    07 02
    08 02

    RECEIVED NB
    C0 21
    02 01 ACK #1
    00 18
    08 02
    07 02
    05 06 0E B9 2D A9 COMP IP
    02 06 00 00 00 00
    01 04 05 DC 8D 4D

    ----------- authentication ------
    SENDING
    C0 23 PAP REQ
    01 02 00 0C 03 75 64 6E 03 75 64 6E


    RECEIVED
    C0 23 PAP_CODE_AUTH_ACK
    02 02 00 05 00 30 15

    ------------ end authen ----------------------
    SENDING
    80 21 IP
    01 01 REQ #1
    00 22
    03 06 00 00 00 00 IP address
    81 06 00 00 00 00
    82 06 00 00 00 00
    83 06 00 00 00 00
    84 06 00 00 00 00


    RECEIVED
    80 21 IP
    01 01 REQ #1
    00 0A
    02 06 00 2D 0F 00 COMP IP

    SENDING
    80 21 IP
    04 01 REJ #1
    00 0A
    02 06 00 2D 0F 00 comp IP
    <<--- this is where I would have expected the remote ip addess.

    RECEIVED
    80 21 IP
    04 01 REJ #1
    00 10
    82 06 00 00 00 00
    84 06 00 00 00 00
    9D EA

    SENDING NB
    80 21 IP
    01 02 REQ #2
    00 16
    03 06 00 00 00 00 IP address
    81 06 00 00 00 00
    83 06 00 00 00 00


    RECEIVED
    80 FD compression proto
    01 01 REQ #1
    00 0A
    12 06 00 00 00 01
    DB 5D


    SENDING
    C0 21
    08 01 protocol reject #1
    00 12
    80 FD the one above
    01 01
    00 0A 12 06 00 00 00 01 DB 5D

    RECEIVED
    80 21 IP
    01 02 req #2
    00 04
    DF 76

    SENDING
    80 21 IP
    02 02 ACK #2
    00 04

    RECEIVED
    80 21 IP
    03 02 NAK #2
    00 16
    03 06 3D 1E 40 31 IP addr
    81 06 3D 1F E9 01
    83 06 D3 4E D7 C8
    B4 EC

    SENDING
    80 21 IP
    01 03 REQ #2
    00 16
    03 06 3D 1E 40 31 ip address
    81 06 3D 1F E9 01
    83 06 D3 4E D7 C8

    RECEIVED
    80 21 IP
    02 03 ACK #3
    00 16
    03 06 3D 1E 40 31 IP address
    81 06 3D 1F E9 01
    83 06 D3 4E D7 C8
    85 72

    Negotiated local IP: 3D1E4031,
    remote IP: 00000000,
    DNS1 IP: 3D1FE901,
    DNS2 IP: D34ED7C8


  2. Re: remote IP address not being sent

    js2k2000@gmail.com writes:
    > SENDING

    [...]
    > 02 06 00 00 00 00


    ACCM of 0.

    > 01 04 05 DC


    That's weird. Why would you send a request for an MTU of 1500?
    That's the default. There's no reason to ask for the default.

    > RECEIVED

    [...]
    > 01 04 05 DC max


    Oh, good. The peer is confused, too.

    > 02 06 00 0A 00 00


    Uh oh. The peer is asking for ACCM 0x000a0000. This is, of course,
    perfectly legal, but, in the real world, almost all implementations
    that ask for this are horribly broken.

    You'll very likely need to change the ACCM on your side to match.

    > RECEIVED NB

    [...]
    > 05 06 0E B9 2D A9 COMP IP


    What does "COMP IP" mean? That's no IP address or compression option
    there; that's the LCP Magic Number option.

    > RECEIVED
    > C0 23 PAP_CODE_AUTH_ACK
    > 02 02 00 05 00 30 15


    A single NUL byte as a welcome message. Nice.

    > RECEIVED
    > 80 21 IP
    > 01 01 REQ #1
    > 00 0A
    > 02 06 00 2D 0F 00 COMP IP


    Is it possible that this other device is using GSM? I've seen
    numerous reports of anomalous behavior of GSM devices because the
    "standard" that they use doesn't conform to the PPP standards. In
    particular, they wait until IPCP starts to do the 'actual'
    authentication. Thus, the PAP Authenticate-Ack that you get is a
    bald-faced lie, and the actual result of failing to authenticate
    correctly is that IPCP fails to assign an address.

    Maybe "udn"/"udn" isn't your correct user name / password combination
    for this service.

    If it's not GSM or a similar bit of breakage, and the above
    suggestions on the ACCM don't work, then I don't know what's causing
    the problem.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: remote IP address not being sent

    js2k2000@gmail.com wrote:
    > I/m trying to debug some software that uses a PPP client in an embedded
    > device. The ISP PPP server that it connects to never sends a
    > configuration-request with an IP-address field, so the client never
    > learns the remote IP address.


    > When I connect from a WinXP PC using the Microsoft supplied PPP client
    > the ISP does send a configuration-request with an IP-address field.


    > Anyone know what would cause this?


    A client configured to request the ISP authenticate itself to the client?

    > This is the PPP sequence, Note that SENDING is from the Clients
    > perspective.


    So noted.
    ....

    > ----------- authentication ------
    > SENDING
    > C0 23 PAP REQ
    > 01 02 00 0C 03 75 64 6E 03 75 64 6E


    The client requests that the ISP authenticate itself to it with PAP.
    I've never known of any ISP that would authenticate itself to a client.

    > RECEIVED
    > C0 23 PAP_CODE_AUTH_ACK
    > 02 02 00 05 00 30 15


    Even though the ISP Acks the PAP request it is, in reality, done.

    > ------------ end authen ----------------------


    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"

  4. Re: remote IP address not being sent

    In article <1122476172.273100.17490@g47g2000cwa.googlegroups.c om>,
    wrote:
    >I/m trying to debug some software that uses a PPP client in an embedded
    >device. The ISP PPP server that it connects to never sends a
    >configuration-request with an IP-address field, so the client never
    >learns the remote IP address.


    Why do you care? As long as you have an IP address for yourself,
    the IP address of the machine you're connected to is of little use.

    >When I connect from a WinXP PC using the Microsoft supplied PPP client
    >the ISP does send a configuration-request with an IP-address field.


    Same ISP?

    >Anyone know what would cause this?
    >
    >This is the PPP sequence, Note that SENDING is from the Clients
    >perspective.
    >
    >SENDING
    >C0 21
    >01 01 CONF_REQ #1
    >00 18
    >08 02 ACFC
    >07 02 PFC
    >05 06 0E B9 2D A9 magic #
    >02 06 00 00 00 00 ACCM = 0x00000000
    >01 04 05 DC
    >
    >RECEIVED
    >C0 21
    >01 01 CONF_REQ #1
    >00 1C
    >01 04 05 DC max
    >02 06 00 0A 00 00 ACCM = 0x000a0000
    >03 04 C0 23 authen = PAP
    >05 06 3C 5E 8D DD magic
    >07 02 comp
    >08 02 comp
    >6E B0 (crc)
    >
    >SENDING
    >C0 21
    >02 01 ACK #1
    >00 1C
    >01 04 05 DC
    >02 06 00 0A 00 00 COMP IP
    >03 04 C0 23
    >05 06 3C 5E 8D DD
    >07 02
    >08 02
    >
    >RECEIVED NB
    >C0 21
    >02 01 ACK #1
    >00 18
    >08 02
    >07 02
    >05 06 0E B9 2D A9 COMP IP
    >02 06 00 00 00 00
    >01 04 05 DC
    >8D 4D (crc)


    Pretty normal so far...

    >----------- authentication ------
    >SENDING
    >C0 23 PAP REQ
    >01 02
    >00 0C
    >03 75 64 6E
    >03 75 64 6E
    >
    >
    >RECEIVED
    >C0 23 PAP_CODE_AUTH_ACK
    >02 02
    >00 05
    >00
    >30 15 (crc)


    Looks good...

    >------------ end authen ----------------------
    >SENDING
    >80 21 IP
    >01 01 REQ #1
    >00 22
    >03 06 00 00 00 00 IP address
    >81 06 00 00 00 00
    >82 06 00 00 00 00
    >83 06 00 00 00 00
    >84 06 00 00 00 00
    >
    >
    >RECEIVED
    >80 21 IP
    >01 01 REQ #1
    >00 0A
    >02 06 00 2D 0F 00 COMP IP


    This is where your peer would have first sent you its IP address
    if it wanted you to know it.

    >SENDING
    >80 21 IP
    >04 01 REJ #1
    >00 0A
    >02 06 00 2D 0F 00 comp IP


    Your machine tells the peer you don't want any IP header compression.

    > <<--- this is where I would have expected the remote ip addess.
    >
    >RECEIVED
    >80 21 IP
    >04 01 REJ #1
    >00 10
    >82 06 00 00 00 00
    >84 06 00 00 00 00
    >9D EA (crc)


    The peer tells you it doesn't do NBNS servers.

    >SENDING NB
    >80 21 IP
    >01 02 REQ #2
    >00 16
    >03 06 00 00 00 00 IP address
    >81 06 00 00 00 00
    >83 06 00 00 00 00


    Your machine asks for an IP address and some DNS server addresses.

    >RECEIVED
    >80 FD compression proto
    >01 01 REQ #1
    >00 0A
    >12 06 00 00 00 01
    >DB 5D


    The peer asks to do link level compression.

    >SENDING
    >C0 21
    >08 01 protocol reject #1
    >00 12
    >80 FD the one above
    >01 01
    >00 0A 12 06 00 00 00 01 DB 5D


    Your machine says it doesn't want to do any link level compression.

    (FYI - you don't have to (you're not supposed to) include the
    rejected frame's CRC)

    >RECEIVED
    >80 21 IP
    >01 02 req #2
    >00 04
    >DF 76 (crc)


    The peer negotiates IP with no options.

    >SENDING
    >80 21 IP
    >02 02 ACK #2
    >00 04


    Your machine says it's OK with that.

    >RECEIVED
    >80 21 IP
    >03 02 NAK #2
    >00 16
    >03 06 3D 1E 40 31 IP addr
    >81 06 3D 1F E9 01
    >83 06 D3 4E D7 C8
    >B4 EC


    The peer tells you want your IP address and DNS addresses should be.

    >SENDING
    >80 21 IP
    >01 03 REQ #2
    >00 16
    >03 06 3D 1E 40 31 ip address
    >81 06 3D 1F E9 01
    >83 06 D3 4E D7 C8


    Your machine asks for that IP address and those DNS addresses.

    >RECEIVED
    >80 21 IP
    >02 03 ACK #3
    >00 16
    >03 06 3D 1E 40 31 IP address
    >81 06 3D 1F E9 01
    >83 06 D3 4E D7 C8
    >85 72


    The peer accepts your IP address and DNS addresses.

    >Negotiated local IP: 3D1E4031,
    >remote IP: 00000000,
    >DNS1 IP: 3D1FE901,
    >DNS2 IP: D34ED7C8


    You have your local IP address. Why do you care what the remote's IP
    address is?

    You'd really need a complete dump of the WinXP client dialing into your
    ISP to see what might make the ISP offer it's IP address during IPCP.

    Patrick
    =========== For PPP Protocol Analysis, check out PacketView Pro! ===========
    Patrick Klos Email: patrick@klos.com
    Klos Technologies, Inc. Web: http://www.klos.com/
    =========== "www" stands for Wild Wild West, NOT World Wide Web! ===========


  5. Re: remote IP address not being sent

    Clifford Kite writes:
    > > ----------- authentication ------
    > > SENDING
    > > C0 23 PAP REQ
    > > 01 02 00 0C 03 75 64 6E 03 75 64 6E

    >
    > The client requests that the ISP authenticate itself to it with PAP.
    > I've never known of any ISP that would authenticate itself to a client.


    No ... that's a PAP Authenticate-Request, which is sent by the
    authenticatee (the "client") to the authenticator (the "server" or
    ISP).

    I think you're thinking of CHAP here. PAP is sort of the reverse of
    CHAP, in that CHAP initially sends a Challenge message from the
    authenticator to authenticatee.

    That's not the problem.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  6. Re: remote IP address not being sent

    James Carlson wrote:
    > Clifford Kite writes:
    >> > ----------- authentication ------
    >> > SENDING
    >> > C0 23 PAP REQ
    >> > 01 02 00 0C 03 75 64 6E 03 75 64 6E

    >>
    >> The client requests that the ISP authenticate itself to it with PAP.
    >> I've never known of any ISP that would authenticate itself to a client.


    > No ... that's a PAP Authenticate-Request, which is sent by the
    > authenticatee (the "client") to the authenticator (the "server" or
    > ISP).


    Yes, you're absolutely right.

    > I think you're thinking of CHAP here. PAP is sort of the reverse of
    > CHAP, in that CHAP initially sends a Challenge message from the
    > authenticator to authenticatee.


    No, I just wasn't thinking, period. :/ Thanks for the correction.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"

  7. Re: remote IP address not being sent

    Correction/Clarification.

    I was dialing a ISP half way around the world using a landline, and was
    having trouble connecting. I used several of the available telephone
    numbers. What I have discovered since the original posting is that some
    of the servers do supply a remote IP address and some do not.

    I have tested with WinXP and the router that I am working on. Having or
    not having the remote IP does not impact the WinXP data transfers. The
    tests have shown that the router needs to have the remote IP in order
    for it to operate. So I have concluded that the PPP client in the
    router is a bit deficient.

    Internally the routers PPP client remote IP is defaulted to 0.0.0.0.
    When the link goes up, if it does not receive the remote IP it stays
    0.0.0.0. It then uses this address when it updates the route table
    default gateway entry.

    Although I'm not working on the PPP software I may have to fix the
    problem. So...
    If no remote IP is received, what address should be used instead?
    What RFC covers this issue?

    And now for your comments.

    > That's weird. Why would you send a request for an MTU of 1500?
    > That's the default. There's no reason to ask for the default.
    >

    Well that's what it does
    >
    > Uh oh. The peer is asking for ACCM 0x000a0000. This is, of course,
    > perfectly legal, but, in the real world, almost all implementations
    > that ask for this are horribly broken.
    >

    Thats very well possible.

    > You'll very likely need to change the ACCM on your side to match.
    >
    > > RECEIVED NB

    > [...]
    > > 05 06 0E B9 2D A9 COMP IP

    >
    > What does "COMP IP" mean? That's no IP address or compression option
    > there; that's the LCP Magic Number option.


    my mistake
    >
    > ...
    >
    > Is it possible that this other device is using GSM? ....


    Doubtfull
    >
    > --
    > James Carlson, KISS Network
    > Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677



  8. Re: remote IP address not being sent

    js2k2000@gmail.com writes:
    > I have tested with WinXP and the router that I am working on. Having or
    > not having the remote IP does not impact the WinXP data transfers. The
    > tests have shown that the router needs to have the remote IP in order
    > for it to operate. So I have concluded that the PPP client in the
    > router is a bit deficient.


    Just configure it to have an arbitrary address. If the peer doesn't
    want to give you an address, and if your local implementation needs
    it, then picking *ANY* address should be fine. Try 192.168.1.1.

    This is actually not that uncommon an issue, and I think Bill Unruh
    gave good advice on this thread.

    > Although I'm not working on the PPP software I may have to fix the
    > problem. So...
    > If no remote IP is received, what address should be used instead?


    Any that you want.

    > What RFC covers this issue?


    None. It's not a standards-related issue but rather a quality-of-
    implementation issue. (Of course, you can always look over RFC 1332
    if you want.)

    > > Is it possible that this other device is using GSM? ....

    >
    > Doubtfull


    Worth a shot, as you provided little information about what actual PPP
    implementations and other equipment were involved in the problem.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  9. Re: remote IP address not being sent

    js2k2000@gmail.com writes:

    >Correction/Clarification.


    >I was dialing a ISP half way around the world using a landline, and was
    >having trouble connecting. I used several of the available telephone
    >numbers. What I have discovered since the original posting is that some
    >of the servers do supply a remote IP address and some do not.


    >I have tested with WinXP and the router that I am working on. Having or
    >not having the remote IP does not impact the WinXP data transfers. The


    Win sends a default which the router accepts. It does not matter which
    number.

    >tests have shown that the router needs to have the remote IP in order
    >for it to operate. So I have concluded that the PPP client in the
    >router is a bit deficient.


    >Internally the routers PPP client remote IP is defaulted to 0.0.0.0.
    >When the link goes up, if it does not receive the remote IP it stays
    >0.0.0.0. It then uses this address when it updates the route table
    >default gateway entry.


    Put
    10.1.1.1:
    into /etc/ppp/options.
    >Although I'm not working on the PPP software I may have to fix the
    >problem. So...


    No problem.

    >If no remote IP is received, what address should be used instead?

    o
    >What RFC covers this issue?


    None. It does not matter. The only purpose of that remote address is for
    the routing tables in your computer. Nothing else in the world knows or
    cares what you call the other end of a ppp link.


    >And now for your comments.


    >> That's weird. Why would you send a request for an MTU of 1500?
    >> That's the default. There's no reason to ask for the default.
    >>

    >Well that's what it does


    I thought you were in control. It is a bug in the software. Not serious.


+ Reply to Thread