Ubuntu Touch devices are using cellular DNS servers over wifi connection

Bug #1270189 reported by Jamie Strandboge on 2014-01-17
70
This bug affects 14 people
Affects Status Importance Assigned to Milestone
Canonical System Image
High
John McAleely
network-manager (Ubuntu)
Undecided
Unassigned
network-manager (Ubuntu RTM)
Undecided
Unassigned

Bug Description

On my Nexus 4, build 121 with TMobile, when I am on wifi, I correctly get a 192.168 ip and DNS entries for this network (on wlan0) -- fine. When I am in range of cellular data, I get an ip address from TMobile and am given DNS entries that aren't on the same network as the TMobile ip address (on rmnet_usb0). The problem is, the DNS entries from TMobile are preferred over the ones from the wifi network such that while wlan0 is correctly setup as the default route, DNS queries are being made to the TMobile DNS servers over wlan0 because there are no explicit routes to these servers. This is problematic because the remote DNS server may not respond to queries coming from out of network or site policy may disallow the use of foreign DNS servers-- both of which result in slow (or possibly failing) DNS queries since the cellular DNS is checked first. Also, where it did work, these queries could incur charges when the user is intending to use only wifi. In the case of (at least) TMobile, this could be a security concern because the well-known TMobile DNS servers are on the private '10.' network, which opens the possibility for a rogue DNS server to be on the private wifi network with this ip address.

This could be fixed in (at least) four ways:
 1) when on wifi, don't merge the DNS servers on cellular networks at all which forces the device to use the ones available on the site (wlan0). This is guaranteed to not incur changes
 2) when on wifi, merge the DNS server from the cellular network, but add them after the ones on the wifi network. This will try the site's DNS first and only if they fail, fallback to the cellular DNS. This may incur charges under certain circumstances
 3) add an explicit route to the cellular DNS servers through rmnet_usb0. This will bypass the site DNS with all queries going through cellular DNS. This will incur charges and would make the device unable to resolve site-local names.
 4) same as '2', but also add explicit routes for the cellular name servers. This should only incur charges if wifi DNS fails

I think '3' is out. '2' and '4' seems most intuitive (with '4' perhaps most correct). '1' seems also ok.

# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 192.168.x.1 0.0.0.0 UG 0 0 0 wlan0
100.152.35.128 0.0.0.0 255.255.255.252 U 0 0 0 rmnet_usb0
192.168.x.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0

 Jan 17 07:36:38 ubuntu-phablet NetworkManager[1130]: <info> Auto-activating connection '/310260575949457/context1'.
Jan 17 07:36:38 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) starting connection '/310260575949457/context1'
Jan 17 07:36:38 ubuntu-phablet NetworkManager[1130]: <info> (/ril_0): device state change: disconnected -> prepare (reason 'none') [30 40 0]
Jan 17 07:36:38 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 1 of 5 (Device Prepare) scheduled...
Jan 17 07:36:38 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 1 of 5 (Device Prepare) started...
Jan 17 07:36:38 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 1 of 5 (Device Prepare) complete.
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> (/ril_0): IPv4 static configuration:
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> address 100.152.35.130/30
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> DNS 10.177.0.34
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> DNS 10.168.183.116
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 2 of 5 (Device Configure) scheduled...
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 2 of 5 (Device Configure) starting...
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> (/ril_0): device state change: prepare -> config (reason 'none') [40 50 0]
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 2 of 5 (Device Configure) successful.
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 3 of 5 (IP Configure Start) scheduled.
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 2 of 5 (Device Configure) complete.
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 3 of 5 (IP Configure Start) started...
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> (/ril_0): device state change: config -> ip-config (reason 'none') [50 70 0]
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 5 of 5 (IPv4 Configure Commit) scheduled...
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 4 of 5 (IPv6 Configure Timeout) scheduled...
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 3 of 5 (IP Configure Start) complete.
Jan 17 07:36:41 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 5 of 5 (IPv4 Commit) started...
Jan 17 07:36:42 ubuntu-phablet NetworkManager[1130]: <info> (/ril_0): device state change: ip-config -> secondaries (reason 'none') [70 90 0]
Jan 17 07:36:42 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 5 of 5 (IPv4 Commit) complete.
Jan 17 07:36:42 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 4 of 5 (IPv6 Configure Timeout) started...
Jan 17 07:36:42 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) Stage 4 of 5 (IPv6 Configure Timeout) complete.
Jan 17 07:36:42 ubuntu-phablet NetworkManager[1130]: <info> (/ril_0): device state change: secondaries -> activated (reason 'none') [90 100 0]
Jan 17 07:36:42 ubuntu-phablet NetworkManager[1130]: <info> Writing DNS information to /sbin/resolvconf
Jan 17 07:36:42 ubuntu-phablet dnsmasq[2189]: setting upstream servers from DBus
Jan 17 07:36:42 ubuntu-phablet dnsmasq[2189]: using nameserver 10.168.183.116#53
Jan 17 07:36:42 ubuntu-phablet dnsmasq[2189]: using nameserver 10.177.0.34#53
Jan 17 07:36:42 ubuntu-phablet dnsmasq[2189]: using nameserver 192.168.x.x#53
Jan 17 07:36:42 ubuntu-phablet dnsmasq[2189]: using nameserver 208.67.222.222#53
Jan 17 07:36:42 ubuntu-phablet dnsmasq[2189]: using nameserver 208.67.220.220#53
Jan 17 07:36:42 ubuntu-phablet NetworkManager[1130]: <info> Activation (/ril_0) successful, device activated.

tags: added: avengers
description: updated
Tony Espy (awe) wrote :

@Jamie

Apparently this bug list hasn't been triaged in a long time...

Can you still reproduce this on current RTM or vivid-devel images?

Changed in network-manager (Ubuntu):
status: New → Incomplete
assignee: nobody → Jamie Strandboge (jdstrand)
tags: added: connectivity
Jamie Strandboge (jdstrand) wrote :

$ system-image-cli -i
current build number: 219
device name: mako
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed
last update: 2015-04-03 07:02:59
version version: 219
version ubuntu: 20150403
version device: 20150116
version custom: mako-1.1

This appears to still be a problem since I can see in tcpdump on the local router that the phone is sending traffic to 4 different resolvers simultaneously, including the ones on T-Mobile network, all through the default route.

$ sudo tcpdump ... -n port 53 and host 192.168.x.x
...
08:58:11.007249 IP 192.168.x.x.64237 > 208.67.222.222.53: 35626+ A? www.debian.org. (32)
08:58:11.007249 IP 192.168.x.x.64237 > 208.67.220.220.53: 35626+ A? www.debian.org. (32)
08:58:11.007249 IP 192.168.x.x.64237 > 10.177.0.34.53: 35626+ A? www.debian.org. (32)
08:58:11.007249 IP 192.168.x.x.64237 > 10.168.187.116.53: 35626+ A? www.debian.org. (32)
08:58:11.023251 IP 208.67.220.220.53 > 192.168.x.x.64237: 35626 2/0/0 A 140.211.15.34, A 128.31.0.62 (64)
08:58:11.023251 IP 208.67.222.222.53 > 192.168.x.x.64237: 35626 2/0/0 A 140.211.15.34, A 128.31.0.62 (64)

Changed in network-manager (Ubuntu):
status: Incomplete → New
assignee: Jamie Strandboge (jdstrand) → nobody

I too am having DNS issues that may well be related to this report.

When my BQ Ubuntu Edition phone is connected to my home network and I have BT parental controls enabled, connections are blocked and I receive the following error message if I try to access the web through the browser:

"You're seeing this page because BT Parental Controls is active and you are attempting to connect to a DNS server outside of our network. You may have selected a different server in you network settings or installed an application that uses an alternative service."

Other functionality requiring internet access is also blocked.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in network-manager (Ubuntu):
status: New → Confirmed

I created a tail file in /etc/resolvconf/resolv.conf.d and added BT's primary DNS which seems to workaround my problem.

EricDHH (ericdhh) wrote :

BQ aquaris 4.5 ubuntu 14.10 (r21)

My phone is able to switch from cell to wifi but not vice versa. Here i have doubled the APN entry for t-mobile and have to change between the two when leaving the house. Otherwise none of the web services is working.

EricDHH (ericdhh) wrote :

BQ aquaris 4.5 ubuntu 14.10 (r22)

Since upgrade this bug is fixed for me, i can carry the device between 2 wifi and the cell radio without problems now.

rm-rubinstein,

Can you tell me how you created that tail file as I am having the same issue.

Thanks

Tony Espy (awe) wrote :

@Jamie

I think this explains the behavior I often see when enabling WiFi and it auto-connects to a known AP. NM shows the connection as active ( ie. nmcli d ), the routing table it correct, pinging an IP address works, however for the first 30-90s after the connection comes up, DNS lookups fail. I think this is one of the underlying causes of users complaining about networking failing when they activate WiFi on Touch devices.

That said, unwinding this may be a bit tricky as NM keeps both connections active, but sets WiFi as the default route. As the DNS Servers were added in order to dnsmasq, and unwinding this in NM might be tricky, I wonder if patching this in dnsmasq is the right way to go? I'll do some investigation of dnsmasq's DBus API. If we changed dnsmasq to reverse the ordering of DNS servers. The only issue here is whether all of the DNS servers for an interface are added as group or not. If they're added individually, then reversing the order would have the effect of reversing the individual DNS servers for a particular interface too, which might not be desired behavior.

Changed in canonical-devices-system-image:
status: New → Confirmed
importance: Undecided → High
milestone: none → ww40-2015
assignee: nobody → John McAleely (john.mcaleely)
milestone: ww40-2015 → none
milestone: none → ww40-2015
Changed in canonical-devices-system-image:
milestone: ww40-2015 → backlog
Lorn Potter (lorn-potter) wrote :

Is there any reason to keep both connections active at the same time?

Obviously it needs to be able to connect to mobile data when wifi is connected for HERE/agps, but I think it just needs to download satellite data once (I could be wrong it might need to keep downloading this data)

Tony Espy (awe) wrote :

@Lorn

It was designed this way in order to make the switching from WiFi back to the mobile data connection fast. Re-working this fundamental design decision IMHOP would be a significant amount of work, and it's not like our current queue of NM related is empty...

I think in the short term if we're able to dedicate cycles to this bug, the best approach would be to re-work how DNS is handled when WiFi is enabled and mobile data is active. My gut tells me that instead of just adding the new DNS servers when WiFi is enabled, that we remove the existing name servers, then re-add them *after* the WiFi nameservers.

Also, I'm not sure that mobile data is needed for downloading HERE/AGPS data, this is something we'd need to discuss with tvoss. That said, it *is* required for MMS to work properly.

flohack (flori-bin) wrote :

I am not sure if this is the right place but I see similar behaviour here with my BQ 5... I am online at my home with WiFi, however if I leave my home the phone does sometimes not switch to network correctly. I can e.g. still see the WiFi indicator shown but in the list of APs there is no green entry. Also, network does show only 3G or E, but not H if I try top open smth.

All internet access ends with immediate connection errors, so it could also be DNS issue. But I am not sure. How can I debug the switch between network & wifi?

Jamie Strandboge (jdstrand) wrote :

FYI (no surprise since the bug is still open), OTA9 exhibits the same behavior.

flohack (flori-bin) wrote :

I am adding some screenshots for this...

flohack (flori-bin) wrote :

For me its better now since last update. Transitions to/from WiFi seem to be nearly always successful.

Set Hallstrom (sakrecoer) wrote :

Any news about this? Still have this issue on my BQ E5 with OTA11...

flohack (flori-bin) wrote :

I just can tell you that I try now on bq E5, E4.5 and Nexus 5... sometimes it still happens but I figured out that normally after 2-3 minutes the WiFi internet settings are being recognized and things start working... So for me it went from not working to working after a long timeout :)

Cédric Bellegarde (gnumdk) wrote :

Same here on MX4 with OTA12...

No DNS while connected to my wifi

Steve Arnold (nerdboy) wrote :

My problem sounds like comment #20 exactly: with no SIM card (yet) and a fresh mako image of stable/ubuntu-developer I have no DNS at all after connecting to WIFI. Manual fudging of resolv.conf makes things work again. I'll install the log viewer next...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers