Nameservers not added to /etc/resolv.conf for 3G, but ARE added to /etc/ppp/resolv.conf

[Mark Shuttleworth]

Binary package hint: network-manager

Occasionally, new 3G connections don't get their nameserver details written into /etc/resolv.conf. The details are written to /etc/ppp/resolv.conf. I don't know if the problem is in NetworkManager or in pppd.

I am using a fairly complicated NetworkManager setup. I've created a wifi network and am then connecting to the net over 3G, so that the rest of the family can surf the net over my connection. I've noticed that /etc/resolv.conf is often *not* updated when the 3G connection is established, though /etc/ppp/resolv.conf appears always to be established. Bizarrely, /etc/resolv.conf is occasionally updated. I can't spot a pattern as to when it might be, or when it won't be.

In syslog I see PPP invoked with a comment like this:

Dec 25 12:33:32 mark-xps-m1330 NetworkManager: <debug> [1261744412.117579] nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock nodefaultroute ttyUSB3 noipdefault noauth usepeerdns lcp-echo-failure 0 lcp-echo-interval 0 ipparam /org/freedesktop/NetworkManager/PPP/8 plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so

My /etc/ppp/options includes the ipcp-accept-local option, if that's relevant.

[Rolf Kutz (vzsze)]

I'm seeing this with a standard network-manager setup on kubuntu 9.10, too, using a UMTS-Modem.

[Mark Shuttleworth (sabdfl)]

Rolf, is it also intermittent with you?

[Rolf Kutz (vzsze)]

On 27/12/09 05:36 -0000, Mark Shuttleworth wrote:
>
>Rolf, is it also intermittent with you?

Yes, it sometimes happens, but most of the time
not, about 10 or 20% of the times.

--
Imagine a world devoid of hypothetical situations...

[Rolf Kutz (vzsze)]

I noticed, that it always happens first time after a reboot or wakeup from suspend.

[islandlinux (islandlinux)]

Confirmed on Netbook Remix 9.10 with a GSM Modem (Sierra Wireless USB 306).

I have had it work the first time when booting.

Out of 10 attempts in which I unplugged the USB modem and plugged it back in /etc/resolv.conf failed to be populated with the proper DNS servers 4 times (40% failure rate). /etc/ppp/resolv.conf was correct each time.

[islandlinux (islandlinux)]

Correction: the /etc/ppp/resolv.conf is not populated either when DNS fails to be propagated to /etc/resolv.conf.

Setting left behind in /etc/ppp/resolv.conf persist after a successful connection. Clearing /etc/ppp/resolv.conf confirmed that the bug does not populate either resolv.conf file upon failure.

[Rolf Kutz (vzsze)]

This bug seems to be fixed in lucid. I get a hardcoded 4.2.2.1 DNS when everything else fails. This works well as a workaround. Would be good to know the original cause of the problem.

[Maarten Bezemer (veger)]

This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.