Debian Bug report logs - #445711
3G modem connection fails the first time

version graph

Package: ppp; Maintainer for ppp is Marco d'Itri <md@linux.it>; Source for ppp is src:ppp.

Reported by: Marcus Better <marcus@better.se>

Date: Sun, 7 Oct 2007 21:24:06 UTC

Severity: important

Tags: patch, upstream

Merged with 563554

Found in version ppp/2.4.4rel-9

Fixed in version ppp/2.4.5-1

Done: Marco d'Itri <md@linux.it>

Bug is archived. No further changes may be made.

Forwarded to linux-ppp@vger.kernel.org

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Marcus Better <marcus@better.se>, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. Full text and rfc822 format available.

Acknowledgement sent to Marcus Better <marcus@better.se>:
New Bug report received and forwarded. Copy sent to Marcus Better <marcus@better.se>, Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Marcus Better <marcus@better.se>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: ppp: IPCP sometimes results in bogus DNS address
Date: Sun, 7 Oct 2007 23:01:48 +0200 (CEST)
Package: ppp
Version: 2.4.4rel-9
Severity: normal

I am connecting to the Swedish mobile ISP Tele2 with PPP using a
Huawei 3G modem. The PPP link is started, but about half the time or
more it ends up assigning bogus DNS addresses 10.11.12.13 and
10.11.12.14 (which cannot in fact be reached). The remaining sessions
give me name servers with public IPs that do work.

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

By checking logs from a number of attempts, I have found the following
pattern: pppd on my side sends up to five 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 as in the success case. If not, then pppd starts
sending a different ConfReq from id=0x6:

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

Note that the ms-dns1 and ms-dns3 parameters are missing.

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 don't know enough about the protocol to understand why pppd changes
the ConfReqs. Also, I'm not sure why there are so many of these
ConfNak messages. Perhaps the server is not happy that pppd ignores
the ms-wins parameters?

(It's quite possible that the other end is misbehaving. I'll try to
contact the ISP, but suspect they won't be very helpful.)

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.23-rc8-melech (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=sv_SE.UTF-8, LC_CTYPE=sv_SE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages ppp depends on:
ii  libc6                        2.6.1-1     GNU C Library: Shared libraries
ii  libpam-modules               0.99.7.1-4  Pluggable Authentication Modules f
ii  libpam-runtime               0.99.7.1-4  Runtime support for the PAM librar
ii  libpam0g                     0.99.7.1-4  Pluggable Authentication Modules l
ii  libpcap0.8                   0.9.7-1     System interface for user-level pa
ii  netbase                      4.30        Basic TCP/IP networking system
ii  procps                       1:3.2.7-4.1 /proc file system utilities

ppp recommends no packages.

-- no debconf information




Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. Full text and rfc822 format available.

Acknowledgement sent to Marcus Better <marcus@better.se>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

Message #10 received at 445711@bugs.debian.org (full text, mbox):

From: Marcus Better <marcus@better.se>
To: 445711@bugs.debian.org
Subject: ppp: IPCP sometimes results in bogus DNS address
Date: Wed, 10 Oct 2007 06:53:07 +0200
[Message part 1 (text/plain, inline)]
The changed behaviour after five ConfReq attempts is explained by #445951. The 
reason we get so many rejects seems to be that pppd is ignoring the ms-wins 
options that the other side wants. I don't know what the specs say about 
that.
[signature.asc (application/pgp-signature, inline)]

Noted your statement that Bug has been forwarded to linux-ppp@vger.kernel.org. Request was from Marcus Better <marcus@better.se> to control@bugs.debian.org. (Tue, 30 Oct 2007 20:09:01 GMT) Full text and rfc822 format available.

Tags added: upstream, patch Request was from Marcus Better <marcus@better.se> to control@bugs.debian.org. (Tue, 20 Nov 2007 22:54:05 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. Full text and rfc822 format available.

Acknowledgement sent to Marcus Better <marcus@better.se>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

Message #19 received at 445711@bugs.debian.org (full text, mbox):

From: Marcus Better <marcus@better.se>
To: 445711@bugs.debian.org
Subject: ppp: IPCP sometimes results in bogus DNS address
Date: Tue, 20 Nov 2007 23:52:32 +0100
[Message part 1 (text/plain, inline)]
This patch fixes the problem. It makes pppd accept the WINS settings from the 
remote side.
[ipcp-accept-wins.diff (text/x-diff, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. Full text and rfc822 format available.

Acknowledgement sent to Marcus Better <marcus@better.se>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

Message #24 received at 445711@bugs.debian.org (full text, mbox):

From: Marcus Better <marcus@better.se>
To: James Cameron <james.cameron@hp.com>
Cc: Bill Unruh <unruh@physics.ubc.ca>, linux-ppp@vger.kernel.org, 445711@bugs.debian.org
Subject: Re: IPCP with mobile ISP sometimes gives bogus DNS address
Date: Wed, 21 Nov 2007 06:44:14 +0100
[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





Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. Full text and rfc822 format available.

Acknowledgement sent to Marcus Better <marcus@better.se>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

Message #29 received at 445711@bugs.debian.org (full text, mbox):

From: Marcus Better <marcus@better.se>
To: 445711@bugs.debian.org, control@bugs.debian.org
Subject: Re: IPCP with mobile ISP sometimes gives bogus DNS address
Date: Tue, 8 Jan 2008 14:00:49 +0100
retitle 445711 ppp: bogus DNS address with Huawei 3G modems
thanks

Noting that this happens with 3G modems like Huawei E620 and E220.

The PPP link terminates at the modem, there is no PPP over the air. Apparently the modem firmware waits for some data to come in from the mobile network, which causes the race condition.




Changed Bug title to `ppp: bogus DNS address with Huawei 3G modems' from `ppp: IPCP sometimes results in bogus DNS address'. Request was from Marcus Better <marcus@better.se> to control@bugs.debian.org. (Tue, 08 Jan 2008 13:09:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. Full text and rfc822 format available.

Acknowledgement sent to Marc Haber <mh+debian-bugs@zugschlus.de>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

Message #36 received at 445711@bugs.debian.org (full text, mbox):

From: Marc Haber <mh+debian-bugs@zugschlus.de>
To: Marcus Better <marcus@better.se>, 445711@bugs.debian.org, 445711-submitter@bugs.debian.org
Cc: Marc Haber <mh+debian-bugs@zugschlus.de>
Subject: Re: Bug#445711: IPCP with mobile ISP sometimes gives bogus DNS address
Date: Wed, 9 Jul 2008 15:14:39 +0200
severity #445711 important
thanks

On Tue, Jan 08, 2008 at 02:00:49PM +0100, Marcus Better wrote:
> Noting that this happens with 3G modems like Huawei E620 and E220.

It also happens with various Option and Novatel products. I guess it's
a general problem which should _really_ be fixed for lenny.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 72739835




Severity set to `important' from `normal' Request was from Marc Haber <mh+debian-bugs@zugschlus.de> to control@bugs.debian.org. (Wed, 09 Jul 2008 13:15:10 GMT) Full text and rfc822 format available.

Message sent on to Marcus Better <marcus@better.se>:
Bug#445711. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. (Wed, 17 Dec 2008 14:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Johannes Spanier <jospanier@web.de>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Wed, 17 Dec 2008 14:03:03 GMT) Full text and rfc822 format available.

Message #46 received at 445711@bugs.debian.org (full text, mbox):

From: Johannes Spanier <jospanier@web.de>
To: 445711@bugs.debian.org
Subject: IPCP with mobile ISP sometimes gives bogus DNS address
Date: Wed, 17 Dec 2008 14:59:53 +0100
Its a race condition between most 3G cards and sticks and the 3G network, NOT with pppd. And thus not a BUG in pppd

use "connect-delay 5000" in /etc/ppp/options to fix.

Regards
Johannes




Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. (Fri, 23 Jan 2009 05:36:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mikko Rapeli <mikko.rapeli@iki.fi>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Fri, 23 Jan 2009 05:36:02 GMT) Full text and rfc822 format available.

Message #51 received at 445711@bugs.debian.org (full text, mbox):

From: Mikko Rapeli <mikko.rapeli@iki.fi>
To: 445711@bugs.debian.org
Subject: pppd patch for testing
Date: Fri, 23 Jan 2009 07:30:23 +0200
Although this problem is not strictly a PPP one, a patch to pppd might
help. It was mentioned in comp.os.linux.networking discussion (quoted
below) and did the trick for a Huawei E220 USB and an Option PC card.

If I got it right, with the patch pppd asks DNS settings until all IPCP
setings are done, and accepts the peers latest response, which helps
when the peer changes its mind due to information received from the
mobile network.

I tested this on Etch version of ppp, which missing a few other GPRS
and DNS related fixes, mentioned in the Ubuntu bug report
https://bugs.launchpad.net/ubuntu/+source/ppp/+bug/258801

-Mikko

In comp.os.linux.networking I wrote:

On 2009-01-20, Clifford Kite <kite@not.available.tld> wrote:
> A Google search for "GPRS PPP DNS 10.11.12.13" yielded this:
>
> http://www.archivum.info/linux-kernel@vger.kernel.org/2008-07/msg00238.html
>
> The pppd patch seems to be a "try and try again until you get real DNS
> server IPs" approach.  Checkout this later post in the thread by the same
> poster to see why:
>
> http://www.archivum.info/linux-kernel@vger.kernel.org/2008-07/msg09189.html
>
> Patching pppd seems a bit extreme to me.  Once the DNS servers are known
> I would personally prefer to manually put them in /ect/resolv.conf and
> seek out and remove the usepeerdns pppd option.  That option would likely
> in the script /etc/ppp/peers/gprs (as in 'pppd call gprs') or something
> called by it.

I tried the patch and it works with a Huawei USB and an Option PC card
modems. I can remove all sleeps and pppd call gprs with success straight
from udev scripts when the modems are connected.

If I got it right, the patch forces pppd to use the latest received DNS
configuration from the peer instead of the first one. That would be the
correct thing to do with these modems, but I'm not sure what else this
might break. A quick look at the PPP rfc does not say this would be
wrong.

For comparison I took AT command and PPP logs from a Vista machine which
uses the Vodafone connection manager:
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/vista_ModemLog_HUAWEI%20Mobile%20Connect%20-%203G%20Modem.txt
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/vista_ppp.log

Here are successfull connection setups with and without the patch:
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/ppp_log_huawei_fixed_pppd.txt
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/ppp_log_success_without_ppp_fix.txt

I will host failing cases too when I manage to copy some older log files
from the host in question.

-Mikko




Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. (Fri, 23 Jan 2009 14:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Mikko Rapeli <mikko.rapeli@iki.fi>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Fri, 23 Jan 2009 14:33:02 GMT) Full text and rfc822 format available.

Message #56 received at 445711@bugs.debian.org (full text, mbox):

From: Mikko Rapeli <mikko.rapeli@iki.fi>
To: 445711@bugs.debian.org
Subject: Re: pppd patch for testing
Date: Fri, 23 Jan 2009 16:27:29 +0200
I verified the patch[1] also with Debian Lenny ppp version 2.4.4rel-10.1
and the Huawei E220. Here are logs of failure without the patch and
success with the patch applied. udev fired up 'pppd call gprs' when
/dev/ttyUSB came available.

http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/ppp_log_failure_without_ppp_fix.txt
http://koti.kapsi.fi/~mcfrisk/gprs_debug/qualcomm_ppp/ppp_log_success_with_ppp_fix.txt

-Mikko

[1] http://www.archivum.info/linux-kernel@vger.kernel.org/2008-07/msg00238.html




Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. (Tue, 20 Oct 2009 14:39:10 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jelle de Jong <jelledejong@powercraft.nl>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Tue, 20 Oct 2009 14:39:10 GMT) Full text and rfc822 format available.

Message #61 received at 445711@bugs.debian.org (full text, mbox):

From: Jelle de Jong <jelledejong@powercraft.nl>
To: 445711@bugs.debian.org
Subject: ppp sometimes receives bogus dns with 3G hsdpa modems
Date: Tue, 20 Oct 2009 16:22:51 +0200
Hello everybody,

I was redirected to this bug report when asking for information about 
this behaviour.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445711

There is talk here about using a patch and/or using "connect-delay 5000" 
in /etc/ppp/options.

I am wondering if this patch is included in debian testing or ustable? 
rmadison show me stable, testing and unstable all use the same 
2.4.4rel-10.1 version.

So what can I do to fix this issue on my machines, is the connect-delay 
enough?

Thanks in advance,

Jelle





Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. (Mon, 16 Nov 2009 18:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Marcus Better <marcus@better.se>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Mon, 16 Nov 2009 18:12:03 GMT) Full text and rfc822 format available.

Message #66 received at 445711@bugs.debian.org (full text, mbox):

From: Marcus Better <marcus@better.se>
To: 445711@bugs.debian.org, Jelle de Jong <jelledejong@powercraft.nl>
Subject: ppp: bogus DNS address with Huawei 3G modems
Date: Mon, 16 Nov 2009 18:57:49 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Did you try setting the ipcp-max-failure option to 30? That seems to do
it in a lot of cases.

Cheers,

Marcus
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAksBkpoACgkQXjXn6TzcAQlQOQCgk9Zv8rJ3iuqnAj62jcMoRd+L
UrIAoLP6bHJPAY+REZYYINj68jWkD2OU
=avYG
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. (Mon, 16 Nov 2009 19:36:22 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jelle de Jong <jelledejong@powercraft.nl>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Mon, 16 Nov 2009 19:36:22 GMT) Full text and rfc822 format available.

Message #71 received at 445711@bugs.debian.org (full text, mbox):

From: Jelle de Jong <jelledejong@powercraft.nl>
To: Marcus Better <marcus@better.se>
Cc: 445711@bugs.debian.org
Subject: Re: ppp: bogus DNS address with Huawei 3G modems
Date: Mon, 16 Nov 2009 20:29:42 +0100
Hi Marcus,

Marcus Better wrote:
> Did you try setting the ipcp-max-failure option to 30? That seems to do
> it in a lot of cases.

Thanks for the tip I already set the ipcp-max-failure and
connect-delay. But last week the wrong DNS settings happens again. I
got a munin trend monitoring tool that now checks the DNS every 5
minutes so i can see and get a warning when it happens again.

My current settings:

echo '/dev/ttyUSB0
7200000
user vodafone
connect "/usr/sbin/chat -v -f /etc/chatscripts/mobile-vodafone.chat"
#crtscts
#modem
#noccp
#nobsdcomp
#novj
#lock
#hide-password
noauth
usepeerdns
noipdefault
#mtu 1492
mtu 1412
persist
connect-delay 5000
ipcp-max-failure 30
maxfail 0
holdoff 20
defaultroute replacedefaultroute' | sudo tee
/etc/ppp/peers/mobile-vodafone

Best regards,

Jelle




Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. (Wed, 16 Dec 2009 18:48:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Hilber <debian-bugs@toh.cx>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Wed, 16 Dec 2009 18:48:06 GMT) Full text and rfc822 format available.

Message #76 received at 445711@bugs.debian.org (full text, mbox):

From: Thomas Hilber <debian-bugs@toh.cx>
To: 445711@bugs.debian.org
Subject: Re: ppp: bogus DNS address with Huawei 3G modems
Date: Wed, 16 Dec 2009 19:45:15 +0100
if a solution becomes available it probably will apply to here also:

https://bugzilla.redhat.com/show_bug.cgi?id=467004




Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. (Wed, 06 Jan 2010 07:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Thomas Hilber <debian-bugs@toh.cx>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Wed, 06 Jan 2010 07:51:03 GMT) Full text and rfc822 format available.

Message #81 received at 445711@bugs.debian.org (full text, mbox):

From: Thomas Hilber <debian-bugs@toh.cx>
To: 445711@bugs.debian.org
Subject: Re: ppp: bogus DNS address with Huawei 3G modems
Date: Wed, 6 Jan 2010 08:48:22 +0100
we've successfully tested following patch:

https://bugzilla.redhat.com/show_bug.cgi?id=467004#c31

for me the issue now is solved.

Cheers
  Thomas




Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#445711; Package ppp. (Tue, 19 Jan 2010 22:27:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Karel Carva <karel.carva@fysik.uu.se>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Tue, 19 Jan 2010 22:27:07 GMT) Full text and rfc822 format available.

Message #86 received at 445711@bugs.debian.org (full text, mbox):

From: Karel Carva <karel.carva@fysik.uu.se>
To: 445711@bugs.debian.org
Subject: DNS problem solved with ipcp-max-failure
Date: Tue, 19 Jan 2010 23:17:13 +0100
I've had a similar problem with ppp 2.4.5 (from Opensuse 11.2). When 
connecting with Huawei E220 to Tele2, pppd did not assign nameservers at 
all in about 4 from 5 cases (strange, maybe it ignores the bogus answer 
now but does not set the correct value). Setting ipcp-max-failure option 
to 30 solves the problem. The problem actually appeared either after the 
upgrade to this ppp version or something was changed at Tele2, it used 
to work fine before.

Best regards,
Karel




Forcibly Merged 445711 563554. Request was from Marcus Better <marcus@bindows.net> to control@bugs.debian.org. (Wed, 10 Feb 2010 20:03:04 GMT) Full text and rfc822 format available.

Added indication that 445711 affects network-manager Request was from Marcus Better <marcus@bindows.net> to control@bugs.debian.org. (Wed, 10 Feb 2010 20:03:06 GMT) Full text and rfc822 format available.

Changed Bug title to '3G modem connection fails the first time' from 'ppp: bogus DNS address with Huawei 3G modems' Request was from Marcus Better <marcus@bindows.net> to control@bugs.debian.org. (Wed, 10 Feb 2010 20:03:08 GMT) Full text and rfc822 format available.

Reply sent to Marco d'Itri <md@linux.it>:
You have taken responsibility. (Sun, 18 Jul 2010 23:36:13 GMT) Full text and rfc822 format available.

Notification sent to Marcus Better <marcus@better.se>:
Bug acknowledged by developer. (Sun, 18 Jul 2010 23:36:13 GMT) Full text and rfc822 format available.

Message #97 received at 445711-close@bugs.debian.org (full text, mbox):

From: Marco d'Itri <md@linux.it>
To: 445711-close@bugs.debian.org
Subject: Bug#445711: fixed in ppp 2.4.5-1
Date: Sun, 18 Jul 2010 23:32:09 +0000
Source: ppp
Source-Version: 2.4.5-1

We believe that the bug you reported is fixed in the latest version of
ppp, which is due to be installed in the Debian FTP archive:

ppp-dev_2.4.5-1_all.deb
  to main/p/ppp/ppp-dev_2.4.5-1_all.deb
ppp-udeb_2.4.5-1_i386.udeb
  to main/p/ppp/ppp-udeb_2.4.5-1_i386.udeb
ppp_2.4.5-1.diff.gz
  to main/p/ppp/ppp_2.4.5-1.diff.gz
ppp_2.4.5-1.dsc
  to main/p/ppp/ppp_2.4.5-1.dsc
ppp_2.4.5-1_i386.deb
  to main/p/ppp/ppp_2.4.5-1_i386.deb
ppp_2.4.5.orig.tar.gz
  to main/p/ppp/ppp_2.4.5.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 445711@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Marco d'Itri <md@linux.it> (supplier of updated ppp package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 19 Jul 2010 01:00:53 +0200
Source: ppp
Binary: ppp ppp-udeb ppp-dev
Architecture: source i386 all
Version: 2.4.5-1
Distribution: unstable
Urgency: low
Maintainer: Marco d'Itri <md@linux.it>
Changed-By: Marco d'Itri <md@linux.it>
Description: 
 ppp        - Point-to-Point Protocol (PPP) - daemon
 ppp-dev    - Point-to-Point Protocol (PPP) - development files
 ppp-udeb   - Point-to-Point Protocol (PPP) - package for Debian Installer (udeb)
Closes: 377670 377987 388712 437339 437789 445711 445951 482699 509200 515590 577799 582035 584318
Changes: 
 ppp (2.4.5-1) unstable; urgency=low
 .
   * New upstream release. (Closes: #515590)
     + Fix authentication on second time around with multilink and persist.
       (Closes: #377670)
     + Increase default IPCP Conf-Nak limit. (Closes: #445711, #445951)
   * Added patch git-20100307 with the upstream changes since the release.
   * Removed the following patches which have been merged upstream:
     pppoe_cleanup, pppoe_fixinclude, fix_close_fd0, fix_mschapv2_ppp.
   * Removed patch pppoatm_fix_mtu since the affected code has been removed.
   * Added patch radius_enanchements.
   * Added patch always_setsid: always create a new process group.
   * Added patch ipv6-accept-remote from Fedora.
   * Added patch dont-exit-pado-timeout to prevent pppd persist from
     exiting in the event of a PPPoE PADO timeout. (Closes: #377987)
   * Added patch update_if_pppol2tp: update include/linux/if_pppol2tp.h to
     match current kernel definitions, from Ubuntu. (LP: #600947)
   * Added a simple example configuration for mobile connectsions.
   * proxyarp is now disabled by default in /etc/ppp/options. (Closes: #388712)
   * Use $@ instead of $* in the link scripts. (Closes: #437339)
   * Correctly restart pppoe-discovery in the udeb. (Patch by alexander
     barakin.) (Closes: #582035)
   * Backup resolv.conf with interface-specific file names to better support
     multilink. (Patch by alex samad). (Closes: #584318)
   * Allow the nostrip option to work. (Closes: #437789)
   * Updated debconf translation: pt_BR, tr. (Closes: #577799, #509200)
   * Packaging converted to quilt. (Closes: #482699)
Checksums-Sha1: 
 e4f9c03b8fa061a1830b530bdb2785c6bd884fab 984 ppp_2.4.5-1.dsc
 cb977b31584e3488e08a643aaa672fdb229d2e78 684342 ppp_2.4.5.orig.tar.gz
 6fefea8b8a4be75fe1fd099f0120d4fe69f2fc22 93114 ppp_2.4.5-1.diff.gz
 c4375d32d071561a5bea47040593a074e3544834 344934 ppp_2.4.5-1_i386.deb
 91522f9c886fd5fc12abee4528dd0f23512d87f6 157348 ppp-udeb_2.4.5-1_i386.udeb
 983d7dbb4c48f7041e35b224ab46951d31e2ea76 57214 ppp-dev_2.4.5-1_all.deb
Checksums-Sha256: 
 0ad869030a5105bfed51943f8e5b6f815c1303424a9d77fd30d90d12594707b6 984 ppp_2.4.5-1.dsc
 43317afec9299f9920b96f840414c977f0385410202d48e56d2fdb8230003505 684342 ppp_2.4.5.orig.tar.gz
 17adf949011956ab27f6a8250ae20b90f86c18bd8631f120acd7175a3487e42c 93114 ppp_2.4.5-1.diff.gz
 686acf34e75832f95d848150da5fcecfb981d5265efccb8bd2615c734b13f9c4 344934 ppp_2.4.5-1_i386.deb
 08c4d9e4715448c9138a93ef3ff0d410d35692b4439b4ab6c7b9b5ed1d09244e 157348 ppp-udeb_2.4.5-1_i386.udeb
 cdf666bd1548b760a39a0dd9e673d583b143d3167363ff8698a8623fe5563da3 57214 ppp-dev_2.4.5-1_all.deb
Files: 
 f07aaf396e85fd4bf01c3189e89fe028 984 admin optional ppp_2.4.5-1.dsc
 4621bc56167b6953ec4071043fe0ec57 684342 admin optional ppp_2.4.5.orig.tar.gz
 e6a91ca5cf5d22bc4bc8471e54162c26 93114 admin optional ppp_2.4.5-1.diff.gz
 9d430899bdc737572557e61dfe2ae92d 344934 admin optional ppp_2.4.5-1_i386.deb
 5136d3e3e17a1c09977db9677b9a8891 157348 debian-installer optional ppp-udeb_2.4.5-1_i386.udeb
 f273456df0342656d088c5688c246c95 57214 devel extra ppp-dev_2.4.5-1_all.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAkxDjCoACgkQFGfw2OHuP7FhBQCfXX6aLXzw5+fSw2udN4EK8DEj
1IkAnjGAU6XWyBBwhaNeLlD2y7rJ2Jdt
=6M5f
-----END PGP SIGNATURE-----





Reply sent to Marco d'Itri <md@linux.it>:
You have taken responsibility. (Sun, 18 Jul 2010 23:36:14 GMT) Full text and rfc822 format available.

Notification sent to Frederic MASSOT <frederic@juliana-multimedia.com>:
Bug acknowledged by developer. (Sun, 18 Jul 2010 23:36:14 GMT) Full text and rfc822 format available.

Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Fri, 20 Aug 2010 07:31:54 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 23 13:47:15 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.