Gets bogus DNS servers during PPP negotiation

I noticed a similar report in http://ubuntuforums.org/showpost.php?p=5515318&postcount=182

I've tried this a few more times, and haven't been able to reproduce it again, but the log shows that this happened at least once. This may be a quirk of the modem.

I'm told that 10.11.12.13 and .14 are given by some providers/modems inappropriately. Perhaps this can be detected and corrected somehow.

I saw the same addresses in my resolv.conf more than once and always thought that i get bogus addresses through ppp.

On Wed, Aug 27, 2008 at 11:02:03AM -0000, Alexander Sack wrote:
> I saw the same addresses in my resolv.conf more than once and always
> thought that i get bogus addresses through ppp.

Maybe it only happens sometimes, I'm not sure. It may be a red herring that
it worked with ifupdown.

--
 - mdz

Also happens on my machine. About half of the time I get the bogus dns 10.11.12.13 and 14. I use huawei e220 modem. The dns data in the mobile-broadband-provider-info is correct for my provider. How is network-manager even supposed to know which provider to use? Didn't find any such setting.

On Sat, Sep 13, 2008 at 05:31:10PM -0000, pivo wrote:
> Also happens on my machine. About half of the time I get the bogus dns
> 10.11.12.13 and 14. I use huawei e220 modem. The dns data in the mobile-
> broadband-provider-info is correct for my provider. How is network-
> manager even supposed to know which provider to use? Didn't find any
> such setting.
>

Can you try to not use NM, but wvdial.conf to connect through that
modem and see whether you can reproduce this bogus DNS when trying
multiple times?

 - Alexander

I see the notebook only every other weekend :) and I will try wvdial next time. Right now vodafone-mobile-connect from https://forge.betavine.net/projects/vodafonemobilec/ is used on the notebook instead of the network-manager and DNS works all the time. The vodafone app allows to set DNS manually and I did just that, so may be that's the reason.

On Wed, Sep 17, 2008 at 12:37:17PM -0000, pivo wrote:
> I see the notebook only every other weekend :) and I will try wvdial
> next time. Right now vodafone-mobile-connect from
> https://forge.betavine.net/projects/vodafonemobilec/ is used on the
> notebook instead of the network-manager and DNS works all the time. The
> vodafone app allows to set DNS manually and I did just that, so may be
> that's the reason.
>
Yeah. BTW, that should be possible for NM too. go to connection editor
and edit the "IPv4 Settings" tab for your 3 connection. You can select
either "Automatic (Addresses only)", which allows you to set your dns
servers manually.

 - Alexander

I go nm-connection-editor -> Mobile Broadband -> GSM Connection -> Edit and there are two tabs Mobile Broadband and PPP. No IPv4 tab. The wired connection has IPv4 tab, mobile connection does not.

This broken behaviour of providing invalide DNS servers is normal, I gave a bit of an explanation in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/248630

I just found this bug exactly because NM 0.7 (last package in hardy) does have the ipv4, but when I choose "Automatic (PPP) addresses only" and define the DNS servers and search domain, it still uses the broken DNS info coming from the network.

Any suggestions?

There is a patch that fixes this problem but as far as I can tell it has not made its way into the upstream ppp source. What is happening is that the mobile ISP is demanding that the client accept MS DNS servers which ppp refuses to do so the connection is terminated. From my experimentation is not ISP specific rather than cell specific. For example I have AT&T it will work in one "area" and fail across town, still on the same AT&T network.

Patch is located here:

http://marc.info/?l=linux-ppp&m=119559914711075&w=2

I just patched the ppp package and it works so far. I moved the original pppd binary out of the way and replaced with the new one several times. Works with the patched one fails with the original. I did that this work on Intrepid Alpha 6.

This appears to be a ppp bug. I added the debian bug which has an initial evaluation too.

more info suggests an option is required:

http://mail.gnome.org/archives/networkmanager-list/2008-September/msg00165.html

and according to that a patch (which probably needs some love to make it work on our pppd version):

http://osdir.com/ml/linux.ppp/2007-11/msg00006.html

oops. oversaw pete's reply. Pete, will you take care that this patch makes it into the pppd package?

The patch still needs some work. I've been traveling quite a bit over the last two weeks and found a few cases where the carrier wants to give us 3 MS DNS address and the patch as is just dosen't deal with it. I'll create a new patch that accepts up to 3 MS DNS servers... Got to love them standards.

Like Pivo, I get the same problem ~50% of the time. 3 Mobile network (UK), Huawei 169 modem.

Regardless of the patch, I wondered if, since 10.11.12.13/14 = broken connection, the connection couldn't automatically be dropped and redialed in this situation?

[[Apologies for clicking whatever I clicked at the top of this page that added an affected package. It was not clear that would happen and I had an 'attack of the clicks'. Sorry.]]

i have a similar problem :

Oct 5 22:47:59 Eee901 kernel: [ 142.323137] PPP generic driver version 2.4.2
Oct 5 22:48:00 Eee901 pppd[6412]: Using interface ppp0
Oct 5 22:48:00 Eee901 pppd[6412]: Connect: ppp0 <--> /dev/ttyUSB0
Oct 5 22:48:00 Eee901 pppd[6412]: CHAP authentication succeeded
Oct 5 22:48:00 Eee901 pppd[6412]: CHAP authentication succeeded
Oct 5 22:48:00 Eee901 kernel: [ 142.612241] PPP BSD Compression module registered
Oct 5 22:48:00 Eee901 kernel: [ 142.737674] PPP Deflate Compression module registered

Oct 5 22:48:04 Eee901 pppd[6412]: Could not determine remote IP address: defaulting to 10.64.64.64 <--------------- i have this

Oct 5 22:48:04 Eee901 pppd[6412]: local IP address 78.130.77.160
Oct 5 22:48:04 Eee901 pppd[6412]: remote IP address 10.64.64.64
Oct 5 22:48:04 Eee901 pppd[6412]: primary DNS address 194.79.69.129
Oct 5 22:48:04 Eee901 pppd[6412]: secondary DNS address 62.169.67.171

and i have to remove from resolv.conf the first DNS because many pages do not open.

---------- windows ---------------

 Endereço IP . . . . . . . . . . . : 78.130.77.144

 Máscara de sub-rede . . . . . . . : 255.255.255.255

 Gateway predefinido . . . . . . . : 78.130.77.144

 Servidor DHCP . . . . . . . . . . : 78.130.77.253

 Servidores DNS. . . . . . . . . . : 194.79.69.129

                                                62.169.67.171

Any ideas ??

Pete mentioned to me that he had made some adjustments to the patch he found, and that this was now working reliably for him.

Pete, could you attach that patch here?

my problem will be solved when only the dns from the ipv4 settings is applied. For now the setting is ignored. Untill then i have to manually delete the first dns from resolv.conf for all the webpages to open. Funny since it works ok on W*ndo**

I had one other corner case worked out but it caused unexpected issues with one tower/provider I hit. Like dumping. I'm reverting back to the original patch and will work on cleaning up the DNS issue. For Intrepid we just need to use the original patch as it does work better and allow a connection.

This bug was fixed in the package ppp - 2.4.4rel-10ubuntu2

---------------
ppp (2.4.4rel-10ubuntu2) intrepid; urgency=low

  * fix LP: #258801; Gets bogus DNS servers during PPP negotiation; we apply
    the patch from http://marc.info/?l=linux-ppp&m=119559914711075&w=2
    - add debian/patches/zzzz_lp258801_fix_ppp_dns.patch

 -- Alexander Sack <email address hidden> Thu, 16 Oct 2008 03:17:37 +0200

I have Ubuntu 8.10 with the fixed package and the bug is still here (Hauwei e169 modem with polish Play operator). The dns are set to 10.11.12.13 and (...).14 no matter if I use wvdial or network-manager. Sometimes (can't find out why) the proper dns are set, but very seldom. I have to start the connection many times to get it work.

Piotr, Pete said that there were still corner cases. Maybe you are struck by such?.

I would suggest to use the mobile wizard to setup your connection. The provider database has fixed DNS entries, which should make this "ppp" bug less intrusive.

The wizard is missing my provider (quite new) - Play.
APN: Internet
Number: *99#
user: none
password: none
DNS: dynamic
or (usually works with those):
89.108.195.20
89.108.195.21

The wizard is missing my provider (quite new) - Play. I doubt it could help - I tried lots of configurations, spend lot of my time on messing with the network-manager options. Nothing helps. It just sometimes connects, sometimes not.

APN: Internet
Number: *99#
user: none
password: none
DNS: dynamic
or (usually works with those):
89.108.195.20
89.108.195.21

Often providers have a support page with the right information. Would be helpful if you could provide that info.

Anyway, please file a bug for your missing provider info against the mobile-broadband-provider-info package: https://bugs.edge.launchpad.net/ubuntu/+source/mobile-broadband-provider-info.

Lets continue discussion there.

I have ppp 2.4.4rel-10ubuntu2 on intrepid but the bug it is still there.

Yes, still happening with 2.4.4rel-10ubuntu2 on 3 UK. Although perhaps less.

apparently, this bug happens less frequently now, but still happens. Milestoning for SRU.

In my case it is happening in 9 out of 10 attempts

On Wed, Oct 29, 2008 at 09:19:45AM -0000, Alexander Sack wrote:
> ** Changed in: ppp (Ubuntu Intrepid)
> Assignee: (unassigned) => Pete Graner (pgraner)
>

The other issue here is that NM doesn't overwrite the bogus values it
received from ppp even if you set Automatic (addresses only) in the
ip4setting tab in connection editor.

I submitted a patch upstream for that particular NM issue:

 http://mail.gnome.org/archives/networkmanager-list/2008-October/msg00372.html

 - Alexander

Also, when in full auto, NM should detect the bogus configuration and issue a warning or reset the connection.

emilio, no we should fix ppp instead.

Alexander, as far as I understood the bogus dns 10.11.12.13 is issued when something goes wrong (even in situations not related with this ms-wins problem). If not NM at least ppp should issue a more formal warning.

Hmm, I always suspected that my provider was the faulty link here, never thought that 10.11.12.13 where globally classed as faulty... (Hehe I really should have thought of that after looking more closely at the ip-address...)

As a side note, vodafone-mobile-connect from https://forge.betavine.net/projects/vodafonemobilec/ could detect that these faulty DNS servers where issued and issued a bubble popup style warning about that the user might need to disconnect and reconnect to correct this.

If the bug cannot be fixed on it's own (the provider may be the one whos sending 10.11.12.13...), then Network Manager should both issue a formal warning as well as ask if the user wants to use the last known good DNS servers for that connection instead.

I retract my previous 'happening less' statement regarding 2.4.4rel-10ubuntu2 on 3 UK... Must have just had a few lucky days.

I would note that the dozen or so times I've connected under Windows using the 3 Mobile dialler software (that came built into the modem's pretend CD drive), the connection is good first time, every time - DNS is always fine.

So by all means warn users that the connection is invalid (and ideally provide a nice user-friendly 'reconnect' button), but it seems to me that some PPP setting or communication with the modem/network is not happening under Linux that is happening under Windows.

If found this http://blog.kishfy.com/2006/11/logging-ppp-sessions-in-windows-xp.html to log PPP in XP. Would it be helpful to attach a few Windows PPP connection logs to this bug report? Anything else we could learn from XP whilst I'm getting dirty and booting it?

might be that we also need

 http://git.ozlabs.org/?p=ppp.git;a=commitdiff_plain;h=f8191bf07df374f119a07910a79217c7618f113e

and

http://git.ozlabs.org/?p=ppp.git;a=commitdiff_plain;h=2e09ef6886bbf00bc5a9a641110f801e372ffde6

Pete, can you take a look?

I have huawei e169 and vodafone mobile connect expresscard and they both had this problem with bogus dns servers.

I tried those patches applied to the ppp package from network-manager team PPA (ppp - 2.4.4rel-10ubuntu2~nm1 ) and they work for me. After I applied those patches I got correct dns settings 9 out of 10 times (one time there were no DNS servers received) with NetworkManager! And of course I also reverted back to the unpatched version and started to receive bogus dns servers again.

Without these patches the vodafone expresscard was unusable for me and what I'm heard there are lots of people struggling with this problem. Therefore in my opinion this should be fixed with SRU ASAP.

we have a confirmed fix for at least a bunch of other issues. we should try to get these properly packaged and SRUed asap.

Uploading to jaunty and initiating intrepid SRU procedure for patches named in
  https://bugs.edge.launchpad.net/ubuntu/+source/ppp/+bug/258801/comments/39

For initial confirm see
  https://bugs.edge.launchpad.net/ubuntu/+source/ppp/+bug/258801/comments/40

uploaded ppp_2.4.4rel-10ubuntu3_source.changes to ubuntu/jaunty

uploaded ppp_2.4.4rel-10ubuntu2.8.10.1_source.changes to ubuntu/intrepid-proposed

This bug was fixed in the package ppp - 2.4.4rel-10ubuntu3

---------------
ppp (2.4.4rel-10ubuntu3) jaunty; urgency=low

  * fix LP: #258801; Gets bogus DNS servers during PPP negotiation; we
    apply two more patches from git (details in patch)
    - add debian/patches/zzzz_lp258801_fix_ppp_dns_1.patch
    - add debian/patches/zzzz_lp258801_fix_ppp_dns_2.patch

 -- Alexander Sack <email address hidden> Wed, 19 Nov 2008 14:05:43 +0100

Accepted ppp into intrepid-proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I have just tried to update but ppp is not between the proposed packages

I noticed the same. The binaries are in 2.4.4rel-10ubuntu3 pool:
http://archive.ubuntu.com/ubuntu/pool/main/p/ppp/

but not in intrepid-proposed i386 packages:
http://archive.ubuntu.com/ubuntu/dists/intrepid-proposed/main/binary-i386/Packages.gz

amd-64 on the other hand has the package listed:
http://archive.ubuntu.com/ubuntu/dists/intrepid-proposed/main/binary-amd64/Packages.gz

I don't know where to look for the cause of this problem.

OK. the package for i386 (and many others) "Needs building":
https://launchpad.net/ubuntu/+source/ppp/2.4.4rel-10ubuntu2.8.10.1/+build/792023

What does that mean? It's been over 10 hours since it was queued. Are the build servers just busy or is there some other problem?

I found the binaries and tested them. At least in my case there is no improvement whatsoever. Still get dummy connections without DNS server. The only difference I can notice is in syslog where the following lines are not appearing any more.

Aug 17 13:59:37 perseus pppd[29978]: primary DNS address 10.11.12.13
Aug 17 13:59:37 perseus pppd[29978]: secondary DNS address 10.11.12.14

I attach /var/log/syslog in case of successful and unsuccessful connections

Antti Kaijanmäki [2008-11-20 19:49 -0000]:
> What does that mean? It's been over 10 hours since it was queued. Are
> the build servers just busy or is there some other problem?

They are clogged, yes. I bumped the build score of ppp, should be
available on archive.u.c. in about three hours.

Several of the architectures were already available before Martin did this:

       ppp | 2.4.4rel-10ubuntu2.8.10.1 | intrepid-proposed | source, amd64, i386, lpia, powerpc

(That's looking at Packages.gz, so matches what you'll see on mirrors.)

OK. tested the package and everything works beautifully now for me. Just like my comments on 2008-11-05. I also noticed that sometimes there are no DNS servers received and sometimes when they are received NM doesn't write them to /etc/resolv.conf. I'm sure these are separate issues and not regressions from the update.

Tested here to and things are still not right... DNS still not being set right.

Syslog attached shows initial connection attempts - an automatic one just after logging in that failed, another one that failed, then finally I connected manually and it worked.

I notice that when I get the no DNS problem, there are no DNS entries at all under 'Connection Information' instead of the dreaded 10.11.12.13/14.

I'll do some further testing to establish whether this happens less frequently or the same as before under this ppp version.

maybe this is also correlates to bug 268667 for which a network-manager SRU is now in -proposed. consider to test that together with this ppp package if you still see the bogus DNS entries.

Alexander, thank you for your tips.

Unfortunately the updates you mentioned above, network manager from ppa.launchpad.net/network-manager/ubuntu and the PPP in Proposed, have had no effect.

There is still no valid DNS set ~50% of the time, as per my previous comments. Sometimes I get a good connection right away, sometimes it takes a few attempts, this morning it took 13 attempts before DNS was set and I could use the connection.

Is there any other logs or information I can provide? Are others experiencing this problem? For me bug this is not fixed.

On Wed, Dec 03, 2008 at 03:03:54AM -0000, Jim Kirkpatrick wrote:
> Alexander, thank you for your tips.
>
> Unfortunately the updates you mentioned above, network manager from
> ppa.launchpad.net/network-manager/ubuntu and the PPP in Proposed, have
> had no effect.
>
> There is still no valid DNS set ~50% of the time, as per my previous
> comments. Sometimes I get a good connection right away, sometimes it
> takes a few attempts, this morning it took 13 attempts before DNS was
> set and I could use the connection.
>
> Is there any other logs or information I can provide? Are others
> experiencing this problem? For me bug this is not fixed.
>

OK thanks. Probably I forgot that I havent applied the patch anywhere
when I sent it upstream. Will push a new PPA package soon that should
fix the bug that your manual dns entries are not honoured.

What we are missing for ppp is kind of unclear to me. If anyone has
any ideas let me know. Could be that we are missing yet another
upstream commit in their git ... or the cases we see now are not even
fixed at all.

 - Alexander

For me, the PPA package from a few days ago absolutely fixed the problem.

Before the update, cca. 1 in 20 tries were OK, and since the update it was OK every single connection (I tried it probably around 30 times).

I can confirm the same, I was getting 1 in 3 working, now its 100%

On 7 Dec 2008, at 10:58, Bernhard Bock wrote:

> For me, the PPA package from a few days ago absolutely fixed the
> problem.
>
> Before the update, cca. 1 in 20 tries were OK, and since the update it
> was OK every single connection (I tried it probably around 30 times).
>
> --
> Gets bogus DNS servers during PPP negotiation
> https://bugs.launchpad.net/bugs/258801
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “network-manager” source package in Ubuntu: Invalid
> Status in “ppp” source package in Ubuntu: Fix Released
> Status in network-manager in Ubuntu Intrepid: Invalid
> Status in ppp in Ubuntu Intrepid: Fix Committed
> Status in “ppp” source package in Debian: Confirmed
>
> Bug description:
> Binary package hint: network-manager
>
> I'm attempting to get my 3G card working with Network Manager (see https://wiki.ubuntu.com/SierraMC8775)
> . My most recent problem is that it seems to get the DNS servers
> wrong. The strange thing is that it works when I invoke pppd via
> ifupdown.
>
> I end up with:
>
> Aug 17 13:59:37 perseus pppd[29978]: Could not determine remote IP
> address: defaulting to 10.64.64.64
> Aug 17 13:59:37 perseus pppd[29978]: Cannot determine ethernet
> address for proxy ARP
> Aug 17 13:59:37 perseus pppd[29978]: local IP address 10.116.65.129
> Aug 17 13:59:37 perseus pppd[29978]: remote IP address 10.64.64.64
> Aug 17 13:59:37 perseus pppd[29978]: primary DNS address 10.11.12.13
> Aug 17 13:59:37 perseus pppd[29978]: secondary DNS address 10.11.12.14
>
> 10.11.12.13 and .14 are not the correct DNS server addresses.
>
> In contrast, when using ifupdown, I get the correct addresses,
> though I do see the bogus ones appearing at an early stage of the
> negotiation:
>
> Aug 17 12:41:21 perseus pppd[26075]: sent [IPCP ConfReq id=0x1 <addr
> 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> Aug 17 12:41:22 perseus pppd[26075]: rcvd [IPCP ConfNak id=0x1 <ms-
> dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
> Aug 17 12:41:22 perseus pppd[26075]: sent [IPCP ConfReq id=0x2 <addr
> 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
> Aug 17 12:41:23 perseus pppd[26075]: rcvd [IPCP ConfNak id=0x2 <ms-
> dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
> Aug 17 12:41:23 perseus pppd[26075]: sent [IPCP ConfReq id=0x3 <addr
> 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
> Aug 17 12:41:23 perseus pppd[26075]: rcvd [IPCP ConfReq id=0x4]
> Aug 17 12:41:23 perseus pppd[26075]: sent [IPCP ConfNak id=0x4 <addr
> 0.0.0.0>]
> Aug 17 12:41:23 perseus pppd[26075]: rcvd [IPCP ConfNak id=0x3 <addr
> 10.116.109.88> <ms-dns1 193.113.200.200> <ms-dns3 193.113.200.201>]
> Aug 17 12:41:23 perseus pppd[26075]: sent [IPCP ConfReq id=0x4 <addr
> 10.116.109.88> <ms-dns1 193.113.200.200> <ms-dns3 193.113.200.201>]
> Aug 17 12:41:23 perseus pppd[26075]: rcvd [IPCP ConfAck id=0x4 <addr
> 10.116.109.88> <ms-dns1 193.113.200.200> <ms-dns3 193.113.200.201>]
> Aug 17 12:41:24 perseus pppd[26075]: rcvd [IPCP ConfReq id=0x5]
> Aug 17 12:41:24 perseus pppd[26075]: sent [IPCP ConfAck id=0x5]
> Aug 17 12:41:24 pers...

In my case the bug is still there. May be less frequent then before but it is clearly unsolved.

The -proposed fix seems to resolve problems for many people, so I don't think it should be delayed from -updates, just because it doesn't fix problems for everybody. Or has anyone seen any regressions that were not there before the -proposed?

Then I propose we consider this verified, and people still having problems should file a new bug, since their problem apparently has a different cause.

This bug was fixed in the package ppp - 2.4.4rel-10ubuntu2.8.10.1

---------------
ppp (2.4.4rel-10ubuntu2.8.10.1) intrepid-proposed; urgency=low

  * fix LP: #258801; Gets bogus DNS servers during PPP negotiation; we
    apply two more patches from git (details in patch)
    - add debian/patches/zzzz_lp258801_fix_ppp_dns_1.patch
    - add debian/patches/zzzz_lp258801_fix_ppp_dns_2.patch

 -- Alexander Sack <email address hidden> Wed, 19 Nov 2008 14:05:43 +0100

emilio wrote:
> In my case the bug is still there. May be less frequent then before but
> it is clearly unsolved.
>
>
you are probably hitting some corner case. can you pleaes file a new
bug, and do a manual connect attempt with ppp debug being enabled and
attach what you get?

(also give us your new bug id so interested folks can continue to track
your issue)

Thanks!

If anyone still sees this bug, please try this patch:

http://<email address hidden>/2008-07/msg09189.html

Although this problem is not strictly a PPP one, a patch to pppd might
help. It was mentioned in comp.os.linux.networking discussion[1] and did
the trick for a Huawei E220 USB and an Option PC card on Debian etch
which misses a few other ppp patches related to GPRS and DNS.

http://groups.google.com/group/comp.os.linux.networking/browse_thread/thread/40dc4ddde9f0b40d#

-Mikko

Sorry, correct patch link is

http://<email address hidden>/2008-07/msg00238.html

-Mikko

To everyone still having issues with DNS not being set properly...

As requested by Alexander, I have submitted a new bug report so we can hopefully nail this issue.

Please go to bug 331322 to continue the fun.