Cannot send MMS messages with combined contexts with WiFi connected

This is a regression: in the same situation MMS are being sent in RTM.

$ system-image-cli -i
current build number: 276
device name: krillin
channel: ubuntu-touch/ubuntu-rtm/14.09-proposed
last update: 2015-05-13 16:13:32
version version: 276
version ubuntu: 20150508
version device: 20150505-db7b5bd
version custom: 20150507-685-29-216

$ ip route
default via 192.168.1.1 dev wlan0 proto static
10.138.255.43 dev ccmni0 proto static scope link
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.39 metric 9

The difference might be related to the changes in routing that the newer NM version in vivid incorporated.

Same situation in vivid shows this routing table:

$ ip route
default via 192.168.1.1 dev wlan0 proto static metric 1024
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.34

with

$ ifconfig
ccmni0 Link encap:Ethernet HWaddr 92:bc:7a:76:db:51
          inet addr:10.56.254.68 Mask:255.0.0.0
          UP RUNNING NOARP MTU:1500 Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:168 (168.0 B) TX bytes:0 (0.0 B)

lo ...

wlan0 Link encap:Ethernet HWaddr 38:bc:1a:18:b5:83
          inet addr:192.168.1.34 Bcast:192.168.1.255 Mask:255.255.255.0
          inet6 addr: fe80::3abc:1aff:fe18:b583/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:233 errors:0 dropped:0 overruns:0 frame:0
          TX packets:250 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:87882 (87.8 KB) TX bytes:27411 (27.4 KB)

NetworkManager is supposed to handle adding a specific host route for a MessageProxy present in a combined APN. This doesn't appear to be happening anymore in vivid.

I checked krillin/rtm #22/sim1=ATT sim2=empty.

With WiFi off, the routing table looks like this:

default via 10.186.165.219 dev ccmni0 proto static
66.209.11.32 dev ccmni0 proto static scope link

Note, the MessageProxy from the active APN is 'wireless.cingular.com', which is publicly resolvable to...66.209.11.32.

With WiFi on, the routing table looks like this:

default via 192.168.1.1 dev wlan0 proto static
66.209.11.32 dev ccmni0 proto static scope link
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.8 metric 9

So, when the download manager connects through the proxy, it's data flows over the mobile data interface ( ccmni0 ).

When I flash vivid-devel, on the same device, with the same SIM configuration. When WiFi is off, the routing table looks like this:

default via 10.177.125.140 dev ccmni0 proto static metric 1024

When WiFi is enabled, it looks like this:

default via 192.168.1.1 dev wlan0 proto static metric 1024
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.8

...which means all traffic goes over the WiFi interface.

I've produced similar results on mako/rtm #19/ATT SIM. I haven't yet retried mako/vivid, but I suspect the same problem as with krillin.

Attached is the NetworkManager dispatch script which is supposed to add the MMS Proxy route. This script is part of the lxc-android-config package. I've verified that it exists in our vivid images. For some reason it appears to be broken.

The script is passed the modem_path ( env:DEVICE_IPATH ) and connection ( env:CONNECTION_ID). If either is 'None', the script silently fails. Next it validates both to ensure that they start with "/", if they don't it again silently fails.

Next it does a synchronous DBus call to ConnectionContext.GetProperties() in order to grab 'Settings', and in turn 'Gateway' ( for logging ).

If 'MessageProxy' is found, it's used for new route, else if 'MessageCenter' is found, it's used instead.

The script then attempts to resolve the hostname using socket.gethostbyname(). I *think* this is a no-op if the MessageProxy is specified as dotted network address instead of a hostname.

The script then uses subprocess.call() to add the route. No error checking is done for the "ip route" command.

The bulk of the logic is surrounding by a try/catch block, which does log a "failed to add route" message, however I'm not seeing this in my syslog, so I believe the failure is earlier in the script itself, or maybe the dispatch mechanism isn't properly triggering the script?

I think with some additional logging we should be able to pinpoint the failure...

The regression is due to NM setting DEVICE_IFACE to "ril_0" in version 0.9.10.0 instead of "/ril_0" as in 0.9.8.8.

There has been a change in nm-modem-ofono.c:nm_modem_ofono_new that explains this (MODEM_UID is skipping the slash in the latest version). The patch that creates nm_modem_ofono_new is "add_ofono_support.patch".

It is probable better to keep the change in MODEM_UID for consistency inside NM, so I have changed the script to handle this change. See attached.

@Alfonso

Updated version of the script in comment #5 looks good to me...