IPCP with mobile ISP sometimes gives bogus DNS address

Hi,

I am connecting to the Swedish mobile ISP Tele2 with PPP using a Huawei 3G modem. The PPP link is started, but very often (perhaps half the time or more) it ends up assigning bogus DNS addresses 10.11.12.13 and 10.11.12.14 which cannot be reached. At other times I get name servers with public IPs that do work.

After checking logs from a number of attempts, the following pattern emerges:
pppd on my side sends up to five (=ipcp-max-failure) IPCP ConfReqs, the first with blank info and the remaining like this:

Oct  2 08:08:59 melech pppd[11052]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]

If it receives a ConfReq from the other side before that point, everything works out correctly. If not, then pppd starts sending empty ConfReqs from id=0x6 and on:

Oct  2 08:09:03 melech pppd[11052]: sent [IPCP ConfReq id=0x6 <addr 0.0.0.0>]

That makes the other end send only an IP address at the end:

Oct  2 08:09:03 melech pppd[11052]: rcvd [IPCP ConfAck id=0x8 <addr 83.188.169.123>]

In the success case, it sends both IP address and DNS settings:

Oct  2 08:12:04 melech pppd[11589]: rcvd [IPCP ConfAck id=0x4 <addr 83.188.169.214> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]

I'm not able to make much more of the logs below, perhaps someone can tell what's going on?

This was also reported to the Debian bug tracking system [1].

Regards,

Marcus

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bugD5951

Log of failure case:

Oct  2 08:08:57 melech pppd[11052]: Serial connection established.
Oct  2 08:08:57 melech pppd[11052]: using channel 3
Oct  2 08:08:57 melech pppd[11052]: Using interface ppp0
Oct  2 08:08:57 melech pppd[11052]: Connect: ppp0 <--> /dev/3gmodem
Oct  2 08:08:58 melech pppd[11052]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x260e3aa4> <pcomp> <accomp>]
Oct  2 08:08:58 melech pppd[11052]: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0x4fafaf6> <pcomp> <accomp>]
Oct  2 08:08:58 melech pppd[11052]: sent [LCP ConfNak id=0x0 <auth pap>]
Oct  2 08:08:58 melech pppd[11052]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x260e3aa4> <pcomp> <accomp>]
Oct  2 08:08:58 melech pppd[11052]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x4fafaf6> <pcomp> <accomp>]
Oct  2 08:08:58 melech pppd[11052]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0x4fafaf6> <pcomp> <accomp>]
Oct  2 08:08:58 melech pppd[11052]: sent [PAP AuthReq id=0x1 user="melech" password=<hidden>]
Oct  2 08:08:58 melech pppd[11052]: rcvd [LCP DiscReq id=0x2 magic=0x4fafaf6]
Oct  2 08:08:58 melech pppd[11052]: rcvd [PAP AuthAck id=0x1 ""]
Oct  2 08:08:58 melech pppd[11052]: PAP authentication succeeded
Oct  2 08:08:58 melech pppd[11052]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Oct  2 08:08:59 melech pppd[11052]: rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct  2 08:08:59 melech pppd[11052]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Oct  2 08:09:00 melech pppd[11052]: rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct  2 08:09:00 melech pppd[11052]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Oct  2 08:09:01 melech pppd[11052]: rcvd [IPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct  2 08:09:01 melech pppd[11052]: sent [IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Oct  2 08:09:02 melech pppd[11052]: rcvd [IPCP ConfNak id=0x4 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct  2 08:09:02 melech pppd[11052]: sent [IPCP ConfReq id=0x5 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Oct  2 08:09:03 melech pppd[11052]: rcvd [IPCP ConfNak id=0x5 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct  2 08:09:03 melech pppd[11052]: sent [IPCP ConfReq id=0x6 <addr 0.0.0.0>]
Oct  2 08:09:03 melech pppd[11052]: rcvd [IPCP ConfReq id=0x0]
Oct  2 08:09:03 melech pppd[11052]: sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
Oct  2 08:09:03 melech pppd[11052]: rcvd [IPCP ConfNak id=0x6 <addr 83.188.169.123>]
Oct  2 08:09:03 melech pppd[11052]: sent [IPCP ConfReq id=0x7]
Oct  2 08:09:03 melech pppd[11052]: rcvd [IPCP ConfNak id=0x7 <addr 83.188.169.123>]
Oct  2 08:09:03 melech pppd[11052]: sent [IPCP ConfReq id=0x8 <addr 83.188.169.123>]
Oct  2 08:09:03 melech pppd[11052]: rcvd [IPCP ConfAck id=0x8 <addr 83.188.169.123>]
Oct  2 08:09:04 melech pppd[11052]: rcvd [IPCP ConfReq id=0x1]
Oct  2 08:09:04 melech pppd[11052]: sent [IPCP ConfAck id=0x1]
Oct  2 08:09:04 melech pppd[11052]: Could not determine remote IP address: defaulting to 10.64.64.64
Oct  2 08:09:04 melech pppd[11052]: Cannot determine ethernet address for proxy ARP
Oct  2 08:09:04 melech pppd[11052]: local  IP address 83.188.169.123
Oct  2 08:09:04 melech pppd[11052]: remote IP address 10.64.64.64
Oct  2 08:09:04 melech pppd[11052]: primary   DNS address 10.11.12.13
Oct  2 08:09:04 melech pppd[11052]: secondary DNS address 10.11.12.14
Oct  2 08:09:04 melech pppd[11052]: Script /etc/ppp/ip-up started (pid 11065)

Log of success case:

Oct  2 08:12:00 melech pppd[11589]: Serial connection established.
Oct  2 08:12:00 melech pppd[11589]: using channel 4
Oct  2 08:12:00 melech pppd[11589]: Using interface ppp0
Oct  2 08:12:00 melech pppd[11589]: Connect: ppp0 <--> /dev/3gmodem
Oct  2 08:12:01 melech pppd[11589]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x8d65e535> <pcomp> <accomp>]
Oct  2 08:12:01 melech pppd[11589]: rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <auth chap MD5> <magic 0x4fdc5be> <pcomp> <accomp>]
Oct  2 08:12:01 melech pppd[11589]: sent [LCP ConfNak id=0x3 <auth pap>]
Oct  2 08:12:01 melech pppd[11589]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x8d65e535> <pcomp> <accomp>]
Oct  2 08:12:01 melech pppd[11589]: rcvd [LCP ConfReq id=0x4 <asyncmap 0x0> <auth pap> <magic 0x4fdc5be> <pcomp> <accomp>]
Oct  2 08:12:01 melech pppd[11589]: sent [LCP ConfAck id=0x4 <asyncmap 0x0> <auth pap> <magic 0x4fdc5be> <pcomp> <accomp>]
Oct  2 08:12:01 melech pppd[11589]: sent [PAP AuthReq id=0x1 user="melech" password=<hidden>]
Oct  2 08:12:01 melech pppd[11589]: rcvd [LCP DiscReq id=0x5 magic=0x4fdc5be]
Oct  2 08:12:01 melech pppd[11589]: rcvd [PAP AuthAck id=0x1 ""]
Oct  2 08:12:01 melech pppd[11589]: PAP authentication succeeded
Oct  2 08:12:01 melech pppd[11589]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Oct  2 08:12:02 melech pppd[11589]: rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct  2 08:12:02 melech pppd[11589]: sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Oct  2 08:12:03 melech pppd[11589]: rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct  2 08:12:03 melech pppd[11589]: sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Oct  2 08:12:04 melech pppd[11589]: rcvd [IPCP ConfReq id=0x2]
Oct  2 08:12:04 melech pppd[11589]: sent [IPCP ConfNak id=0x2 <addr 0.0.0.0>]
Oct  2 08:12:04 melech pppd[11589]: rcvd [IPCP ConfNak id=0x3 <addr 83.188.169.214> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
Oct  2 08:12:04 melech pppd[11589]: sent [IPCP ConfReq id=0x4 <addr 83.188.169.214> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
Oct  2 08:12:04 melech pppd[11589]: rcvd [IPCP ConfAck id=0x4 <addr 83.188.169.214> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
Oct  2 08:12:05 melech pppd[11589]: rcvd [IPCP ConfReq id=0x3]
Oct  2 08:12:05 melech pppd[11589]: sent [IPCP ConfAck id=0x3]
Oct  2 08:12:05 melech pppd[11589]: Could not determine remote IP address: defaulting to 10.64.64.64
Oct  2 08:12:05 melech pppd[11589]: Cannot determine ethernet address for proxy ARP
Oct  2 08:12:05 melech pppd[11589]: local  IP address 83.188.169.214
Oct  2 08:12:05 melech pppd[11589]: remote IP address 10.64.64.64
Oct  2 08:12:05 melech pppd[11589]: primary   DNS address 130.244.127.161
Oct  2 08:12:05 melech pppd[11589]: secondary DNS address 130.244.127.169

/etc/ppp/peers/tele2-3g:
-----------------------------------
3gmodem 921600
connect '/usr/sbin/chat -v -f /etc/ppp/tele2-3g.chat' noipdefault
novj
noccp
noauth
local
defaultroute
usepeerdns
debug
----------------------------------

/etc/ppp/tele2-3g.chat:
----------------------------------
TIMEOUT 5
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "NO ANSWER"
ABORT "BUSY"
"" ATZ
OK AT+CPIN00
TIMEOUT 2
OK-AT-OK AT+CGDCONT=1,"IP","internet.tele2.se"
TIMEOUT 5
OK ATDT*99***1#
CONNECT
----------------------------------

/etc/ppp/options is the default, with the following appended:
-------------
deflate 12
bsdcomp 12
predictor1
-------------

G'day Marcus,

I've been the Linux focal point for a 3G deployment in Australia, testing the devices with Linux and as a result I was given one, which I now pay for the use of.

I see this problem you report daily. I don't recall ever *not* seeing the problem. The DNS server IPs listed do not respond when queried.

The solution I use is to run a BIND server locally that uses the root servers. This works, but is probably not as useful as an ISP provided DNS server.

I've been told that the 10.11.12.13 values are an invention by the firmware in the modem, which provides the PPP interface. Others have seen these values despite having no radio coverage, e.g. by operating the unit inside a metal box, or a very long way from a tower.

Therefore the best way to diagnose this may be to (a) examine the data flow on another operating system, determining how it differs, and (b) add features to pppd if possible to handle the unusual behaviour. These features might be as out-of-tree patches, plugins, or finally merged if the project endorses them. I'm interested in testing such changes.

References:

http://quozl.linux.org.au/bp3-usb/

Debug log: [not wrapped]

Oct 31 08:33:13 dors pppd[2770]: rcvd [CHAP Success id=0x1 ""]
Oct 31 08:33:13 dors pppd[2770]: sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
Oct 31 08:33:14 dors pppd[2770]: rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct 31 08:33:14 dors pppd[2770]: sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 0.0.0.0>]
Oct 31 08:33:15 dors pppd[2770]: rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct 31 08:33:15 dors pppd[2770]: sent [IPCP ConfReq id=0x3 <compress VJ 0f 01> <addr 0.0.0.0>]
Oct 31 08:33:16 dors pppd[2770]: rcvd [IPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
Oct 31 08:33:16 dors pppd[2770]: sent [IPCP ConfReq id=0x4 <compress VJ 0f 01> <addr 0.0.0.0>]
Oct 31 08:33:16 dors pppd[2770]: rcvd [IPCP ConfReq id=0x0 <addr 144.135.12.50>]
Oct 31 08:33:16 dors pppd[2770]: sent [IPCP ConfAck id=0x0 <addr 144.135.12.50>]
Oct 31 08:33:16 dors pppd[2770]: rcvd [IPCP ConfRej id=0x4 <compress VJ 0f 01>]
Oct 31 08:33:16 dors pppd[2770]: sent [IPCP ConfReq id=0x5 <addr 0.0.0.0>]
Oct 31 08:33:16 dors pppd[2770]: rcvd [IPCP ConfNak id=0x5 <addr 58.164.11.1>]
Oct 31 08:33:16 dors pppd[2770]: sent [IPCP ConfReq id=0x6 <addr 58.164.11.1>]
Oct 31 08:33:16 dors pppd[2770]: rcvd [IPCP ConfAck id=0x6 <addr 58.164.11.1>]

James Cameron
http://ftp.hp.com.au/sigs/jc/

You request and asyncmap of 0 and pcomp and acomp.

He requests ans asyncmap of 0 pcomp acomp and requests that you authenticate using chap MD5.

You refuse chapMD5 but suggest pap. Note that this is rarely a good idea. You should be willing to use what the isp wants. In this case however it is OK as he agrees, but often the ISP does not. What the ISP wants, the ISP must get, or you go down in flames.

He agrees to your asyncmap pcomp and accomp.

He changes his request to pap. Note again he was under absolutely no obligation to do so.

You agree.

You send your credentials.

NO idea what DiskReq is.

He says your credentials are OK.

You request that he supply you with an IP address and two dns server addresses.

He supplies you with those but also windows server addresses. And below he demands that you accept them. That is apparently a non-negotiable demand for him.
Put in at least one, maybe 2
ms-wins 0.0.0.0
into your pppd options. He wants them for some insane reason. But an ISP's insanity must be catered to or he will go away in a snit.

You say OK you will use the dns, but refuse to use the wins.

He insists.

You again decline, and eventually the two discussions peter out and you go your separate ways.

He supplies you with an address, but by this time he is obviously sulking and goes away eventually.

OK, this time the remote machine does not insist on ms-wins. The ISP probably has a whole bunch of computers answering the phones, and some of them are more obnoxious than others.

Well, the remote guy should have also sent his IP but it does not matter. It is only you that uses that IP address anyway, so whatever it is you know it.

William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     [email protected]
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

LCP disconnection request. I see it too on my 3G modem, when it is working fine. It seems to have no effect, and pppd ignores it. It would be annoying if it had an effect.

Chuckle. Agreed. In this case, it is the firmware of the modem. The on-air radio protocol does not do PPP.

I've heard said that the supplying of an address requires communication over the radio link ... I've seen this step delayed. Most of the other responses are too fast to involve the radio link.

It should be the same modem. Presumably this means that the response of the modem may depend in part on the data it has gathered over the radio link. It is closed-source firmware.

I've had a few debates with people who think that the remote IP address of the link should be something legitimate, but it really does not matter. pppd will work whatever the remote address is, as far as I can tell. The packets are not addressed to that remote address. Point to point routing is by device, not by IP address.

James Cameron
http://ftp.hp.com.au/sigs/jc/

That didn't seem to make a difference. I believe the ms-wins option is only effective for incoming connections, but I may be wrong. See this log, where the session succeeds, but it looks similar to previous ones:

Oct 31 21:44:56 melech pppd[5218]: Serial connection established.
Oct 31 21:44:56 melech pppd[5218]: using channel 7
Oct 31 21:44:56 melech pppd[5218]: Using interface ppp0
Oct 31 21:44:56 melech pppd[5218]: Connect: ppp0 <--> /dev/3gmodem
Oct 31 21:44:57 melech pppd[5218]: sent [LCP ConfReq id=0x1 <asyncmap 
0x0> <magic 0x453fe8e6> <pcomp> <accomp>]
Oct 31 21:44:57 melech pppd[5218]: rcvd [LCP ConfReq id=0x0 <asyncmap 
0x0> <auth chap MD5> <magic 0x50e52ff> <pcomp> <accomp>]
Oct 31 21:44:57 melech pppd[5218]: sent [LCP ConfNak id=0x0 <auth pap>]
Oct 31 21:44:57 melech pppd[5218]: rcvd [LCP ConfAck id=0x1 <asyncmap 
0x0> <magic 0x453fe8e6> <pcomp> <accomp>]
Oct 31 21:44:57 melech pppd[5218]: rcvd [LCP ConfReq id=0x1 <asyncmap 
0x0> <auth pap> <magic 0x50e52ff> <pcomp> <accomp>]
Oct 31 21:44:57 melech pppd[5218]: sent [LCP ConfAck id=0x1 <asyncmap 
0x0> <auth pap> <magic 0x50e52ff> <pcomp> <accomp>]
Oct 31 21:44:57 melech pppd[5218]: sent [PAP AuthReq id=0x1 
user="melech" password=<hidden>]
Oct 31 21:44:57 melech pppd[5218]: rcvd [LCP DiscReq id=0x2 magic=0x50e52ff]
Oct 31 21:44:57 melech pppd[5218]: rcvd [PAP AuthAck id=0x1 ""]
Oct 31 21:44:57 melech pppd[5218]: PAP authentication succeeded
Oct 31 21:44:57 melech pppd[5218]: sent [IPCP ConfReq id=0x1 <addr 
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Oct 31 21:44:58 melech pppd[5218]: rcvd [IPCP ConfNak id=0x1 <ms-dns1 
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 
10.11.12.14>]
Oct 31 21:44:58 melech pppd[5218]: sent [IPCP ConfReq id=0x2 <addr 
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Oct 31 21:44:58 melech pppd[5218]: rcvd [IPCP ConfReq id=0x0]
Oct 31 21:44:58 melech pppd[5218]: sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
Oct 31 21:44:58 melech pppd[5218]: rcvd [IPCP ConfNak id=0x2 <addr 
83.178.248.251> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
Oct 31 21:44:58 melech pppd[5218]: sent [IPCP ConfReq id=0x3 <addr 
83.178.248.251> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
Oct 31 21:44:58 melech pppd[5218]: rcvd [IPCP ConfAck id=0x3 <addr 
83.178.248.251> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
Oct 31 21:44:59 melech pppd[5218]: rcvd [IPCP ConfReq id=0x1]
Oct 31 21:44:59 melech pppd[5218]: sent [IPCP ConfAck id=0x1]
Oct 31 21:44:59 melech pppd[5218]: Could not determine remote IP 
address: defaulting to 10.64.64.64
Oct 31 21:44:59 melech pppd[5218]: Cannot determine ethernet address for 
proxy ARP
Oct 31 21:44:59 melech pppd[5218]: local  IP address 83.178.248.251
Oct 31 21:44:59 melech pppd[5218]: remote IP address 10.64.64.64
Oct 31 21:44:59 melech pppd[5218]: primary   DNS address 130.244.127.161
Oct 31 21:44:59 melech pppd[5218]: secondary DNS address 130.244.127.169

Thanks,

Marcus

Yes, and in this case the remote side did not insist of hte ms-wins. That is the only difference. And the difference comes from the far side. They DEMAND mswins, you do not agree and the split is certain.
That the other side may be inconsistant and idiotic is not anything you can do something about, except finding a new ISP (or is this a modem of some sort).

William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     [email protected]
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

So it remains to patch pppd to accept the ms-wins settings then?

Marcus

Thanks, I will try that!

Marcus

Give it a try, tell us what you find.

James Cameron
http://ftp.hp.com.au/sigs/jc/

It works! I patched pppd to accept the WINS settings from the other side:

Nov 20 23:33:17 melech pppd[25464]: Connect: ppp0 <--> /dev/3gmodem
Nov 20 23:33:18 melech pppd[25464]: sent [LCP ConfReq id=0x1 <asyncmap
0x0> <magic 0x394ac5b7> <pcomp> <accomp>]
Nov 20 23:33:18 melech pppd[25464]: rcvd [LCP ConfReq id=0x0 <asyncmap
0x0> <auth chap MD5> <magic 0x50a91da> <pcomp> <accomp>]
Nov 20 23:33:18 melech pppd[25464]: sent [LCP ConfAck id=0x0 <asyncmap
0x0> <auth chap MD5> <magic 0x50a91da> <pcomp> <accomp>]
Nov 20 23:33:18 melech pppd[25464]: rcvd [LCP ConfAck id=0x1 <asyncmap
0x0> <magic 0x394ac5b7> <pcomp> <accomp>]
Nov 20 23:33:18 melech pppd[25464]: rcvd [LCP DiscReq id=0x1
magic=0x50a91da]
Nov 20 23:33:18 melech pppd[25464]: rcvd [CHAP Challenge id=0x1
<3886094f10ef4afad083954d7af40093>, name = "UMTS_CHAP_SRVR"]
Nov 20 23:33:18 melech pppd[25464]: sent [CHAP Response id=0x1
<8a22f34d3faa17922975defd5b2d6eb2>, name = "melech"]
Nov 20 23:33:18 melech pppd[25464]: rcvd [CHAP Success id=0x1 ""]
Nov 20 23:33:18 melech pppd[25464]: CHAP authentication succeeded
Nov 20 23:33:18 melech pppd[25464]: CHAP authentication succeeded
Nov 20 23:33:18 melech pppd[25464]: sent [IPCP ConfReq id=0x1 <addr
0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Nov 20 23:33:19 melech pppd[25464]: rcvd [IPCP ConfNak id=0x1 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Nov 20 23:33:19 melech pppd[25464]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:20 melech pppd[25464]: rcvd [IPCP ConfNak id=0x2 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Nov 20 23:33:20 melech pppd[25464]: sent [IPCP ConfReq id=0x3 <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:21 melech pppd[25464]: rcvd [IPCP ConfNak id=0x3 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Nov 20 23:33:21 melech pppd[25464]: sent [IPCP ConfReq id=0x4 <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:22 melech pppd[25464]: rcvd [IPCP ConfNak id=0x4 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Nov 20 23:33:22 melech pppd[25464]: sent [IPCP ConfReq id=0x5 <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:23 melech pppd[25464]: rcvd [IPCP ConfNak id=0x5 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Nov 20 23:33:23 melech pppd[25464]: sent [IPCP ConfReq id=0x6 <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:24 melech pppd[25464]: rcvd [IPCP ConfNak id=0x6 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Nov 20 23:33:24 melech pppd[25464]: sent [IPCP ConfReq id=0x7 <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:25 melech pppd[25464]: rcvd [IPCP ConfNak id=0x7 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Nov 20 23:33:25 melech pppd[25464]: sent [IPCP ConfReq id=0x8 <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:26 melech pppd[25464]: rcvd [IPCP ConfNak id=0x8 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Nov 20 23:33:26 melech pppd[25464]: sent [IPCP ConfReq id=0x9 <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:27 melech pppd[25464]: rcvd [IPCP ConfNak id=0x9 <ms-dns1
10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]
Nov 20 23:33:27 melech pppd[25464]: sent [IPCP ConfReq id=0xa <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:27 melech pppd[25464]: rcvd [IPCP ConfReq id=0x0]
Nov 20 23:33:27 melech pppd[25464]: sent [IPCP ConfNak id=0x0 <addr
0.0.0.0>]
Nov 20 23:33:27 melech pppd[25464]: rcvd [IPCP ConfRej id=0xa <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]
Nov 20 23:33:27 melech pppd[25464]: sent [IPCP ConfReq id=0xb <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
Nov 20 23:33:27 melech pppd[25464]: rcvd [IPCP ConfNak id=0xb <addr
83.178.151.127> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
Nov 20 23:33:27 melech pppd[25464]: sent [IPCP ConfReq id=0xc <addr
83.178.151.127> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
Nov 20 23:33:27 melech pppd[25464]: rcvd [IPCP ConfAck id=0xc <addr
83.178.151.127> <ms-dns1 130.244.127.161> <ms-dns3 130.244.127.169>]
Nov 20 23:33:28 melech pppd[25464]: rcvd [IPCP ConfReq id=0x1]
Nov 20 23:33:28 melech pppd[25464]: sent [IPCP ConfAck id=0x1]
Nov 20 23:33:28 melech pppd[25464]: Could not determine remote IP
address: defaulting to 10.64.64.64
Nov 20 23:33:28 melech pppd[25464]: Cannot determine ethernet address
for proxy ARP
Nov 20 23:33:28 melech pppd[25464]: local  IP address 83.178.151.127
Nov 20 23:33:28 melech pppd[25464]: remote IP address 10.64.64.64
Nov 20 23:33:28 melech pppd[25464]: primary   DNS address 130.244.127.161
Nov 20 23:33:28 melech pppd[25464]: secondary DNS address 130.244.127.169
Nov 20 23:33:28 melech pppd[25464]: Script /etc/ppp/ip-up started (pid

25471)

It also requires using the "ipcp-max-failure" pppd option, I set it to 30. The attached patch is against Debian pppd 2.4.4rel-9.

Regards,

Marcus

@@ -723,7 +723,8 @@
 #define LENCIADDRS(neg)		(neg ? CILEN_ADDRS : 0)
 #define LENCIVJ(neg, old)	(neg ? (old? CILEN_COMPRESS : CILEN_VJ) : 0)
 #define LENCIADDR(neg)		(neg ? CILEN_ADDR : 0)
-#define LENCIDNS(neg)		(neg ? (CILEN_ADDR) : 0)
+#define LENCIDNS(neg)		LENCIADDR(neg)
+#define LENCIWINS(neg)		LENCIADDR(neg)
 
     /*
      * First see if we want to change our options to the old

@@ -745,7 +746,9 @@
 	    LENCIVJ(go->neg_vj, go->old_vj) +
 	    LENCIADDR(go->neg_addr) +
 	    LENCIDNS(go->req_dns1) +
-	    LENCIDNS(go->req_dns2)) ;
+	    LENCIDNS(go->req_dns2) +
+            LENCIWINS(go->winsaddr[0]) +
+            LENCIWINS(go->winsaddr[1])) ;
 }
 
 

@@ -819,6 +822,19 @@
 	    neg = 0; \
     }
 
+#define ADDCIWINS(opt, addr)                  \
+    if (addr) { \
+	if (len >= CILEN_ADDR) { \
+	    u_int32_t l; \
+	    PUTCHAR(opt, ucp); \
+	    PUTCHAR(CILEN_ADDR, ucp); \
+	    l = ntohl(addr); \
+	    PUTLONG(l, ucp); \
+	    len -= CILEN_ADDR; \
+	} else \
+	    addr = 0; \
+    }
+
     ADDCIADDRS(CI_ADDRS, !go->neg_addr && go->old_addrs, go->ouraddr,
 	       go->hisaddr);
 

@@ -831,6 +847,10 @@
 
     ADDCIDNS(CI_MS_DNS2, go->req_dns2, go->dnsaddr[1]);
 
+    ADDCIWINS(CI_MS_WINS1, go->winsaddr[0]);
+
+    ADDCIWINS(CI_MS_WINS2, go->winsaddr[1]);
+    
     *lenp -= len;
 }
 

@@ -1167,6 +1187,15 @@
 		try.neg_addr = 1;
 	    no.neg_addr = 1;
 	    break;
+	case CI_MS_WINS1:
+	case CI_MS_WINS2:
+	    if (cilen != CILEN_ADDR)
+		goto bad;
+	    GETLONG(l, p);
+	    ciaddr1 = htonl(l);
+	    if (ciaddr1)
+		try.winsaddr[citype == CI_MS_WINS2] = ciaddr1;
+	    break;
 	}
 	p = next;
     }

@@ -1283,6 +1312,21 @@
 	try.neg = 0; \
     }
 
+#define REJCIWINS(opt, addr) \
+    if (addr && \
+	((cilen = p[1]) == CILEN_ADDR) && \
+	len >= cilen && \
+	p[0] == opt) { \
+	u_int32_t l; \
+	len -= cilen; \
+	INCPTR(2, p); \
+	GETLONG(l, p); \
+	cilong = htonl(l); \
+	/* Check rejected value. */ \
+	if (cilong != addr) \
+	    goto bad; \
+	try.winsaddr[opt == CI_MS_WINS2] = 0; \
+    }
 
     REJCIADDRS(CI_ADDRS, !go->neg_addr && go->old_addrs,
 	       go->ouraddr, go->hisaddr);

@@ -1296,6 +1340,10 @@
 
     REJCIDNS(CI_MS_DNS2, req_dns2, go->dnsaddr[1]);
 
+    REJCIWINS(CI_MS_WINS1, go->winsaddr[0]);
+
+    REJCIWINS(CI_MS_WINS2, go->winsaddr[1]);
+
     /*
      * If there are any remaining CIs, then this packet is bad.
      */

Good to see. I've reviewed the patch briefly, and it seems fine. I've not tested it, as I'm not able to reproduce the conditions easily.

James Cameron
http://ftp.hp.com.au/sigs/jc/

[Correcting CC for Debian bug]

One thing I didn't check is how this patch works if the ms-wins option is used. I re-uses the same address fields in the request struct. Perhaps two new fields should be added instead.

Marcus