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

[email]js2k2000@gmail.com[/email] writes:[color=blue]
> SENDING[/color]
[...][color=blue]
> 02 06 00 00 00 00[/color]

ACCM of 0.
[color=blue]
> 01 04 05 DC[/color]

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.
[color=blue]
> RECEIVED[/color]
[...][color=blue]
> 01 04 05 DC max[/color]

Oh, good. The peer is confused, too.
[color=blue]
> 02 06 00 0A 00 00[/color]

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.
[color=blue]
> RECEIVED NB[/color]
[...][color=blue]
> 05 06 0E B9 2D A9 COMP IP[/color]

What does "COMP IP" mean? That's no IP address or compression option
there; that's the LCP Magic Number option.
[color=blue]
> RECEIVED
> C0 23 PAP_CODE_AUTH_ACK
> 02 02 00 05 00 30 15[/color]

A single NUL byte as a welcome message. Nice.
[color=blue]
> RECEIVED
> 80 21 IP
> 01 01 REQ #1
> 00 0A
> 02 06 00 2D 0F 00 COMP IP[/color]

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 <james.d.carlson@sun.com>
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

[email]js2k2000@gmail.com[/email] wrote:[color=blue]
> 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.[/color]
[color=blue]
> 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.[/color]
[color=blue]
> Anyone know what would cause this?[/color]

A client configured to request the ISP authenticate itself to the client?
[color=blue]
> This is the PPP sequence, Note that SENDING is from the Clients
> perspective.[/color]

So noted.
....
[color=blue]
> ----------- authentication ------
> SENDING
> C0 23 PAP REQ
> 01 02 00 0C 03 75 64 6E 03 75 64 6E[/color]

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.
[color=blue]
> RECEIVED
> C0 23 PAP_CODE_AUTH_ACK
> 02 02 00 05 00 30 15[/color]

Even though the ISP Acks the PAP request it is, in reality, done.
[color=blue]
> ------------ end authen ----------------------[/color]

--
Clifford Kite Email: "echo [email]xvgr_yvahk-ccc@ri1.arg[/email]|rot13"

In article <1122476172.273100.17490@g47g2000cwa.googlegroups.com>,
<js2k2000@gmail.com> wrote:[color=blue]
>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.[/color]

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.
[color=blue]
>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.[/color]

Same ISP?
[color=blue]
>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)[/color]

Pretty normal so far...
[color=blue]
>----------- 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)[/color]

Looks good...
[color=blue]
>------------ 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[/color]

This is where your peer would have first sent you its IP address
if it wanted you to know it.
[color=blue]
>SENDING
>80 21 IP
>04 01 REJ #1
>00 0A
>02 06 00 2D 0F 00 comp IP[/color]

Your machine tells the peer you don't want any IP header compression.
[color=blue]
> <<--- 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)[/color]

The peer tells you it doesn't do NBNS servers.
[color=blue]
>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[/color]

Your machine asks for an IP address and some DNS server addresses.
[color=blue]
>RECEIVED
>80 FD compression proto
>01 01 REQ #1
>00 0A
>12 06 00 00 00 01
>DB 5D[/color]

The peer asks to do link level compression.
[color=blue]
>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[/color]

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)
[color=blue]
>RECEIVED
>80 21 IP
>01 02 req #2
>00 04
>DF 76 (crc)[/color]

The peer negotiates IP with no options.
[color=blue]
>SENDING
>80 21 IP
>02 02 ACK #2
>00 04[/color]

Your machine says it's OK with that.
[color=blue]
>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[/color]

The peer tells you want your IP address and DNS addresses should be.
[color=blue]
>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[/color]

Your machine asks for that IP address and those DNS addresses.
[color=blue]
>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[/color]

The peer accepts your IP address and DNS addresses.
[color=blue]
>Negotiated local IP: 3D1E4031,
>remote IP: 00000000,
>DNS1 IP: 3D1FE901,
>DNS2 IP: D34ED7C8[/color]

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: [email]patrick@klos.com[/email]
Klos Technologies, Inc. Web: [url]http://www.klos.com/[/url]
=========== "www" stands for Wild Wild West, NOT World Wide Web! ===========

Clifford Kite <kite@see.signature.id> writes:[color=blue][color=green]
> > ----------- authentication ------
> > SENDING
> > C0 23 PAP REQ
> > 01 02 00 0C 03 75 64 6E 03 75 64 6E[/color]
>
> 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.[/color]

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 <james.d.carlson@sun.com>
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

James Carlson <james.d.carlson@sun.com> wrote:[color=blue]
> Clifford Kite <kite@see.signature.id> writes:[color=green][color=darkred]
>> > ----------- authentication ------
>> > SENDING
>> > C0 23 PAP REQ
>> > 01 02 00 0C 03 75 64 6E 03 75 64 6E[/color]
>>
>> 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.[/color][/color]
[color=blue]
> No ... that's a PAP Authenticate-Request, which is sent by the
> authenticatee (the "client") to the authenticator (the "server" or
> ISP).[/color]

Yes, you're absolutely right.
[color=blue]
> 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.[/color]

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

--
Clifford Kite Email: "echo [email]xvgr_yvahk-ccc@ri1.arg[/email]|rot13"

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.
[color=blue]
> 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.
>[/color]
Well that's what it does[color=blue]
>
> 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.
>[/color]
Thats very well possible.
[color=blue]
> You'll very likely need to change the ACCM on your side to match.
>[color=green]
> > RECEIVED NB[/color]
> [...][color=green]
> > 05 06 0E B9 2D A9 COMP IP[/color]
>
> What does "COMP IP" mean? That's no IP address or compression option
> there; that's the LCP Magic Number option.[/color]

my mistake[color=blue]
>
> ...
>
> Is it possible that this other device is using GSM? ....[/color]

Doubtfull[color=blue]
>
> --
> James Carlson, KISS Network <james.d.c..@sun.com>
> 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[/color]

[email]js2k2000@gmail.com[/email] writes:[color=blue]
> 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.[/color]

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.
[color=blue]
> 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?[/color]

Any that you want.
[color=blue]
> What RFC covers this issue?[/color]

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.)
[color=blue][color=green]
> > Is it possible that this other device is using GSM? ....[/color]
>
> Doubtfull[/color]

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 <james.d.carlson@sun.com>
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

[email]js2k2000@gmail.com[/email] writes:
[color=blue]
>Correction/Clarification.[/color]
[color=blue]
>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.[/color]
[color=blue]
>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[/color]

Win sends a default which the router accepts. It does not matter which
number.
[color=blue]
>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.[/color]
[color=blue]
>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.[/color]

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

No problem.
[color=blue]
>If no remote IP is received, what address should be used instead?[/color]
o[color=blue]
>What RFC covers this issue?[/color]

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.

[color=blue]
>And now for your comments.[/color]
[color=blue][color=green]
>> 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.
>>[/color]
>Well that's what it does[/color]

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