Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.networking > #3007 > unrolled thread
| Started by | Hul Tytus <ht@panix.com> |
|---|---|
| First post | 2014-07-01 15:22 +0000 |
| Last post | 2014-07-02 03:28 +0000 |
| Articles | 4 — 3 participants |
Back to article view | Back to comp.os.linux.networking
ppp/ipcp curiosities Hul Tytus <ht@panix.com> - 2014-07-01 15:22 +0000
Re: ppp/ipcp curiosities Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-07-01 12:44 -0400
Re: ppp/ipcp curiosities Hul Tytus <ht@panix.com> - 2014-07-01 22:18 +0000
Re: ppp/ipcp curiosities Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2014-07-02 03:28 +0000
| From | Hul Tytus <ht@panix.com> |
|---|---|
| Date | 2014-07-01 15:22 +0000 |
| Subject | ppp/ipcp curiosities |
| Message-ID | <loujn8$gnq$1@reader1.panix.com> |
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
[toc] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2014-07-01 12:44 -0400 |
| Message-ID | <yzBsv.63873$J82.51608@fx13.iad> |
| In reply to | #3007 |
On Tuesday 01 July 2014 11:22, in comp.os.linux.networking, "Hul Tytus"
<ht@panix.com> wrote:
> 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.
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.
> 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
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Hul Tytus <ht@panix.com> |
|---|---|
| Date | 2014-07-01 22:18 +0000 |
| Message-ID | <lovc41$bu6$1@reader1.panix.com> |
| In reply to | #3008 |
Nice figuring Lew, thanks. The question of why so many occurrances does remain though. Hul Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote: > On Tuesday 01 July 2014 11:22, in comp.os.linux.networking, "Hul Tytus" > <ht@panix.com> wrote: > > 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. > 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 A 2 - 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. > > 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 > -- > Lew Pitcher > "In Skills, We Trust" > PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Moe Trin <ibuprofin@painkiller.example.tld.invalid> |
|---|---|
| Date | 2014-07-02 03:28 +0000 |
| Message-ID | <slrnlr6v3o.14j.ibuprofin@fermi.phx.az.us> |
| In reply to | #3008 |
On Tue, 01 Jul 2014, in the Usenet newsgroup comp.os.linux.networking, in
article <yzBsv.63873$J82.51608@fx13.iad>, Lew Pitcher wrote:
>"Hul Tytus" <ht@panix.com> wrote:
>> 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.
>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.
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.
>So, the local end has to ask "Can I use this address?", and the peer
>has to say "No, use /this one/ instead."
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
[toc] | [prev] | [standalone]
Back to top | Article view | comp.os.linux.networking
csiph-web