IPCP with mobile ISP sometimes gives bogus DNS address

IPCP with mobile ISP sometimes gives bogus DNS address

[Marcus Better]

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+CPIN\000
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
-------------

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[James Cameron]

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/

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[Bill Unruh]

On Tue, 30 Oct 2007, Marcus Better wrote:

> 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>]

You request and asyncmap of 0 and pcomp and acomp.

> Oct  2 08:08:58 melech pppd[11052]: rcvd [LCP ConfReq id=0x0 <asyncmap 0x0> <auth chap MD5> <magic 0x4fafaf6> <pcomp> <accomp>]

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

> Oct  2 08:08:58 melech pppd[11052]: sent [LCP ConfNak id=0x0 <auth pap>]

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.


> Oct  2 08:08:58 melech pppd[11052]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x260e3aa4> <pcomp> <accomp>]

He agrees to your asyncmap pcomp and accomp.

> Oct  2 08:08:58 melech pppd[11052]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth pap> <magic 0x4fafaf6> <pcomp> <accomp>]

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


> Oct  2 08:08:58 melech pppd[11052]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth pap> <magic 0x4fafaf6> <pcomp> <accomp>]

You agree.

> Oct  2 08:08:58 melech pppd[11052]: sent [PAP AuthReq id=0x1 user="melech" password=<hidden>]

You send your credentials.

> Oct  2 08:08:58 melech pppd[11052]: rcvd [LCP DiscReq id=0x2 magic=0x4fafaf6]

NO idea what DiskReq is.

> Oct  2 08:08:58 melech pppd[11052]: rcvd [PAP AuthAck id=0x1 ""]

He says your credentials are OK.

> 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>]

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


> 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>]

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.


> 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>]

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

> 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>]

He insists.

> 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>]

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


> 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>]

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


> 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>]

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.


> 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

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.


> 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+CPIN\000
> 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
> -------------
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
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 |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[James Cameron]

On Tue, Oct 30, 2007 at 05:32:19PM -0700, Bill Unruh wrote:
>> Oct  2 08:08:58 melech pppd[11052]: rcvd [LCP DiscReq id=0x2 
>> magic=0x4fafaf6]
>
> NO idea what DiskReq is.

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.

>> 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>]
>
> 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.

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

>> 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>]
>
> He supplies you with an address, but by this time he is obviously
> sulking and goes away eventually.

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.

>> Log of success case:
>>
>> 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>]
>
> 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.

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.

> 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.

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/

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[Marcus Better]

Bill Unruh wrote:
> 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.

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

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[Bill Unruh]

On Wed, 31 Oct 2007, Marcus Better wrote:

> Bill Unruh wrote:
>>  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.
>
> 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:


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).




>
> 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
>
>

-- 
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 |     unruh@physics.ubc.ca
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[Marcus Better]

Bill Unruh wrote:
> Yes, and in this case the remote side did not insist of hte ms-wins.
> is the only difference. And the difference comes from the far side. They
> DEMAND mswins, you do not agree and the split is certain.

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

Marcus

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[Marcus Better]

James Cameron wrote:
> 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.

Thanks, I will try that!

Marcus

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[James Cameron]

On Thu, Nov 01, 2007 at 09:33:16AM +0100, Marcus Better wrote:
> So it remains to patch pppd to accept the ms-wins settings then?

Give it a try, tell us what you find.

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

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[Marcus Better]

[-- Attachment #1: Type: text/plain, Size: 5844 bytes --]

James Cameron wrote:
>> So it remains to patch pppd to accept the ms-wins settings then?
> 
> Give it a try, tell us what you find.

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

[-- Attachment #2: ipcp-accept-wins.diff --]
[-- Type: text/plain, Size: 2505 bytes --]

--- ppp-2.4.4/pppd/ipcp.c	2007-11-20 23:20:02.022199444 +0100
+++ ppp-2.4.4.mine/pppd/ipcp.c	2007-11-20 23:23:06.210978674 +0100
@@ -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.
      */

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[James Cameron]

On Tue, Nov 20, 2007 at 11:48:52PM +0100, Marcus Better wrote:
> It works! I patched pppd to accept the WINS settings from the other
> side:

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/

Re: IPCP with mobile ISP sometimes gives bogus DNS address

[Marcus Better]

[Correcting CC for Debian bug]

James Cameron wrote:
>> It works! I patched pppd to accept the WINS settings from the other
>> side:

> 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.

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