Nameserver addresses 4.2.2.1 and 4.2.2.2 end up in resolv.conf instead of ISP nameserver addresses -- Huawei E220

I have this on Three in the UK, but AFAIK, it's an issue with the provider (teleco/ISP) not sending it. Disconnecting and Reconnecting from the menu once generally solves it, but network manager should have the sense to do this automatically.

I have a hard time seeing that they don't send it, since it should have trouble in windows too then.

But it even though it's true I agree the network manager should detect that it haven't got any DNS info and try to recover.

Problem with that approach might be that some might not need them (for what reason I don't know or care), but that can easily be solved with a checkbox option.

I also confirm this. But before never happened. Just since Karmic.

usually we encourage users to use the wizard to create their broadband connections - this usually fills in DNS values. a new database with more providers will be uploaded before release.

Ehm, I used the wizard, no DNS from there (and just in case, I also deleted and recreated the connection to make sure there was no bugs there)

fix committed upstream: 294a5e31532b038e9ad31f4f9750fe6fa724da1c

Please test latest dailies from https://launchpad.net/~network-manager/+archive/trunk to verify.

I'll test as soon as I'm on the mobile connection again, thanks :)

I just tested the fix from the network-manager ppa and I confirm that it solves the problem. The DNS settings are correctly retrieved by the provider upon connection and added to /etc/resolv.conf .

I have noticed another buggy behavior regarding mobile broadband, but I may should open a new bug for it. When I boot the pc with the HSDPA modem plugged in, while the modem is mounted as cdrom, the NM does not provide an option for mobile broadband connection. If I unplug and the plug it again, the modem is again mounted as cdrom and also NM recognize the device and enables the mobile broadband connection. I have Huawei E220 modem.

Weird, I can confirm a bit different behavior. I discovered it gives a different dns ip, if the one from my ISP isn't received (I presume that's what's happening, since I haven't seen that IP before).

About the rest, yes you should make a new bug on this or rather search existing bugs. I think I have bugreported behavior like that before, but I'm not sure, haven't had the time to report much lately. But to me it seems rather random from different networkmanager/modemmanger versions, some of them you had to boot it with the modem, some plug the modem in after boot, and currently I experience that booting with the modem then rebooting works best.

@rohdef: You are right! The dns servers added to /etc/resolv.conf are not those provided by the isp. NM has currently set my nameservers to 4.2.2.1 and 4.2.2.2 that resolve to vnsc-pri.sys.gtei.net and vnsc-bak.sys.gtei.net located at USA according to lookup, while I am located at greece. But, even this way I think it is an acceptable workaround when no dns info can be retrieved from the isp though the question why this inability to obtain isp dns info happens almost always on 9.10 while very seldom on 9.04 still remains and it would be good to have it resolved for performance (minimize dns lookup delays) reasons.

 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux
------------------
Description: Ubuntu 9.10
Release: 9.10

I can confirm similar behaviour. My Optus mobile broadband connected to a Windows XP - next to my Koala works fine, plug the modem into my Koala and I get all the right lights on but no DNS.

However sometimes it has worked.

Model is Huawei E160E HSDPA USB Stick

This bug was fixed in the package network-manager - 0.8~rc2-0ubuntu1

---------------
network-manager (0.8~rc2-0ubuntu1) lucid; urgency=low

  * upstream snapshot 2009-11-12 01:22:59 (GMT)
    + 420ea0220c29a45337e239e4c53250a6989160a3
    - ppp: allow update of ppp secrets in all ACTIVATING stages (LP: #432205)
    - core: validate pidfile and quit early if NM is already running (rh #517362)
    - core: preserve wifi and networking enabled/disabled states (bgo #582447)
    - libnm-util: don't allow blank or NULL VPN items or secrets (rh #532084)

  * upstream 0.8-rc1 release
    - libnm-util: client cert shouldn't be required to set priv key (bgo #585570)
    - wifi: poll rfkill status for ipw2x00 devices
    - ppp: increase PPPoE pppd timeout to 30 seconds (debug)
    - wifi: don't allow scan requests when associating
    - wifi: ensure wifi devices are enabled on wakeup if not rfkilled
    - libnm-util: handle PEM files without ending newline (rh #507315)
    - system-settings: cache secrets to protect against nm_connection_clear_secrets
    - dnsmasq: VPN DNS fixes (LP #389006)
    - system-settings: fix crash when deleting wired connections
    - modem: subsitute known-good nameservers if PPP doesn't return any (LP: #434477)
    - core: clear invalid tag on failed connections when sleeping (LP: #456362)
    - wwan: unable to bring up mobile-broadband system connection (LP: #483773)
    - 8021x: fixed problems with invalid connection / client-certs (LP: #245184)

  * upstream 0.8-rc2 release
    - po: update italian translation (bgo #595673)
    - core: fix error when parsing state file for WirelessEnabled fails
    - libnm-util: fix potential crash when encrypting fails
    - modem: ensure deactivation on disable only happens on disable
    - modem: ensure device is deactivated if the modem is disabled
      underneath NM
    - modem: enable modem before connecting if required
    - libnm-glib: add WWAN enable/disable support
    - manager: add WWAN enable/disable support
    - modem: proxy the ModemManager Enabled property
    - manager: generalize rfkill operations
    - core: add statefile support for WWAN devices
    - udev: add support for other types of rfkill switches
    - core: generalize interface for enabling/disabling devices
    - modem: fix enable/disable/disconnect flow
    - system-settings: Fix using hostname from DHCP
    - libnm-util: client certificate should not be required to set
      private key (bgo #585570)

  [ Alexander Sack <email address hidden> ]
  * allow daily builds to be filed against ubuntu bug system;
    to allow this we add report['CrashDB'] = 'ubuntu' to the apport
    hook
    - update debian/source_network-manager.py
  * attach list of system-connection configuration files in apport hook
    - update debian/source_network-manager.py

  [ Mathieu Trudel <email address hidden> ]
  * updated pkcs11 smartcard patch
    - updated debian/patches/lp120363_smartcard_pkcs11.patch
  * updated signals patch for apport
    - updated debian/patches/70_lp145653_no_sigaction_for_crashes.patch
  * add new nm_setting_olpc_mesh_new symbol to libnm-util1.symbols
    - update debian/libnm-util1.symbols
  * add new nm_cl...

This is not simply a bug. It is a "bug" in security procedures and programming procedures:

1. Security: Deliberately faking DNS server data, i.e. putting 4.2.2.1 into /etc/resolv.conf, is a very serious thing. This creates great doubt on the security of Ubuntu (and also of Fedora, where this "bug" is also reported). On whose behalf is this done? Which organization is covertly spying on our DNS lookups and, possibly, forging the responses? I definitely do not want DNS servers in the UK, a foreign NATO country, to be my primary servers (traceroute 4.2.2.1 goes to the UK).

2. Programming: The chosen fake DNS server data "4.2.2.1" is not visible to or changeable by the user in any obvious way before dialling. In other words, it can be described as placed in the software code in stead of in the configuration data. That is extremely bad programming practise.

Can anyone give a plausible reason why the DNS server thing worked perfectly in Ubuntu 9.04 but does not work in 9.10?

Uno Staver> Have you heard about conspiracy theories? I think some reading about those would be rather healthy for you. No it's only a security-problem if you're really paranoid and works with some top secret military equipment, except for the detail that you'd use encrypted connections whereas the problem isn't really valid any more.

And if some agency from UK, US, Afganistan or whereever you might think of wants to spy on us? What would happen? What have do you - or I for that sake - have to hide? And how do you know that your ISP don't work for the Taleban or FBI? Come on you can keep continuing the circle to the infinite.

I still have this problem in Lucid using Network-manager version 0.8-0ubuntu3.

[danne@danne-laptop] ~> cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 4.2.2.1
nameserver 4.2.2.2

I have similar issues on my HP mininote 2133.

I installed the files from the above repository. Now resolv.conf is OK for my ethernet connection, but when I try (with sudo) to ping my router, I get
ping: sendmsg: Operation not permitted

My dns servers do implement DNSSEC.

But then I disconnect the ethernet cable. My wireless connects, and I can now ping my router at 192.168.1.1. But resolv.conf now has no nameservers. If I manually enter them, the internet works.

But eth0 will never work.

According to https://bugzilla.redhat.com/show_bug.cgi?id=467004 it should be fixed, but maybe somehow not included in Ubuntu 10.04 LTS?

Uno Staver I agree with you. Automatically changing dns to 4.2.2.1 caused to me very slow dns responses, because this is foreign dns. It's visible when you right-click nm-applet and select connection info. In karmic this never happened, but in lucid it's happening often. It's not fixed yet. Really should consider to mark this bug as security issue.

I too have this problem. Sometimes it is impossible to get dns information from my provider and in those cases I get 4.2.2.1 and 4.2.2.2 as name servers but they will not resolve any names. My provider is Tele2 in Sweden.

Is there a way to edit the database to correct the name server entries?

I feel that the support for mobile broadband got worse going from Karmic to Lucid. I have other issues too, that I did not have with Karmic.

The original report was:
> When connecting in Karmic to my broadband connection
> the DNS informations isn't received around 70-80%
> of the times I connect, so I need to disconnect and
> reconnect until the info is received. (Confirmed by
> /etc/resolv.conf being empty except for a comment
> by the network manager)

Has this problem been fixed in Precise?

BTW, to work around the problem you can add nameserver addresses as follows

    echo "nameserver 12.34.56.78" | sudo resolvconf -a mytemporarynameserveraddresses

(and you'll have to do this again if you reboot) or delete them as follows.

    sudo resolvconf -d mytemporarynameserveraddresses

To add them permanently, add

    nameserver 12.34.56.78

to /etc/resolvconf/resolv.conf.d/base.

But, again, this is only a workaround.

Hi Thomas!

It took some time for me to grasp what this was all about, I never got any response on this issue.

I never got the U220 to work in a good way in Ubuntu but then Android phones came along with their WLAN tethering ability and I have not used the U220 dongle since then. It is a much faster solution which needs no special drivers or anything.

Anyway thanks for the tip. If I ever need to use the modem again I will have a look at it.

Regards,

Roger

24 jun 2012 kl. 18:13 skrev Thomas Hood:

> The original report was:
>> When connecting in Karmic to my broadband connection
>> the DNS informations isn't received around 70-80%
>> of the times I connect, so I need to disconnect and
>> reconnect until the info is received. (Confirmed by
>> /etc/resolv.conf being empty except for a comment
>> by the network manager)
>
> Has this problem been fixed in Precise?
>
> BTW, to work around the problem you can add nameserver addresses as
> follows
>
> echo "nameserver 12.34.56.78" | sudo resolvconf -a
> mytemporarynameserveraddresses
>
> (and you'll have to do this again if you reboot) or delete them as
> follows.
>
> sudo resolvconf -d mytemporarynameserveraddresses
>
> To add them permanently, add
>
> nameserver 12.34.56.78
>
> to /etc/resolvconf/resolv.conf.d/base.
>
> But, again, this is only a workaround.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/434477
>
> Title:
> network-manager: no dns received with mobile connectio (Huawei E220)
>
> Status in “network-manager” package in Ubuntu:
> Confirmed
>
> Bug description:
> Binary package hint: network-manager
>
> When connecting in Karmic to my broadband connection the DNS
> informations isn't received around 70-80% of the times I connect, so I
> need to disconnect and reconnect until the info is received.
> (Confirmed by /etc/resolv.conf being empty except for a comment by the
> network manager)
>
> I don't know if this relates to the same problem, but I also some
> times have a problem accessing pages after a while, like it somehow
> decided to block all signals. (resolv.conf still has the info and the
> modem shows it's connected)
>
> I hope there's information enough to fix it, otherwise please instruct
> me on what to do to help debugging.
>
> ProblemType: Bug
> Architecture: amd64
> CheckboxSubmission: 2483b723db6bd40eab5dccee54ef36fb
> CheckboxSystem: fb5f7a2788cceff50ba915d7273d1642
> Date: Tue Sep 22 08:43:42 2009
> DistroRelease: Ubuntu 9.10
> IfupdownConfig:
> auto lo
> iface lo inet loopback
> IpRoute:
> 10.64.64.64 dev ppp0 proto kernel scope link src 95.209.250.39
> 169.254.0.0/16 dev ppp0 scope link metric 1000
> default via 10.64.64.64 dev ppp0 proto static
> Package: network-manager 0.8~a~git.20090911t130220.4c77fa0-0ubuntu6
> ProcEnviron:
> LANGUAGE=en_US.UTF-8
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 2.6.31-10.34-generic
> SourcePackage: network-manager
> Uname: Linux 2.6.31-10-generic x86_64
> WpaSupplicantLog:
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net...

Note that upstream's website

    https://live.gnome.org/NetworkManager/MobileBroadband

says

Huawei E220 (firmware versions older than 11.117.09.04.00 (Vodafone only) are known to be problematic; make sure you have 11.117.10.00.00 or later)

See also bug #868034.

Does this bug still affect anyone?

This bug was marked Incomplete some time ago and was supposed to autoclose after 90 days. I'm going to close it manually due to no activity (and likely the issue has gone away/been fixed).