No mobile data connection for mako on wily

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

Deb doesn't connect to mobile network anymore using vivd

I am using a Nexus 7 2013 (LTE)/Mobile. It worked fine on 14.10 and yes I am using the same APN settings.

sudo ubuntu-device-flash --server="http://system-image.tasemnice.eu" touch --channel="ubuntu-touch/ubuntu-rtm/devel" --bootstrap brings up r.20 15.04 and it picks up the mobile network OK

That's because the ubuntu-rtm builds are very outdated.

Something bad is happening in latest mako wily image. After updating from a working image, ofono and network-manager packages are the same version, but if I do ifconfig I see interfaces that were certainly not up previously:

enx928c129913fb Link encap:Ethernet HWaddr 92:8c:12:99:13:fb
          inet6 addr: fe80::908c:12ff:fe99:13fb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:2000 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:2154 (2.1 KB)

enxd221b0f110e3 Link encap:Ethernet HWaddr d2:21:b0:f1:10:e3
          inet6 addr: fe80::d021:b0ff:fef1:10e3/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:2000 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:2154 (2.1 KB)

enxfebb828f5529 Link encap:Ethernet HWaddr fe:bb:82:8f:55:29
          inet6 addr: fe80::fcbb:82ff:fe8f:5529/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:2000 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B) TX bytes:2496 (2.4 KB)

$ system-image-cli -i
current build number: 235
device name: mako
channel: ubuntu-touch/devel-proposed/ubuntu
last update: 2015-06-24 06:00:55
version version: 235
version ubuntu: 20150624
version device: 20150529.1
version custom: 20150624

I also saw that I was unable to make any calls with the phone, even though the indicator showed four bars. The phone application displayed the "no network" label.

I'm seeing the same behavior. Also when I try to send a text message, I get "No SIM card selected. You need to select a SIM card."

If I enable wifi, my phone app now says "T-Mobile" instead of "No network" and I am able to send text messages

I'm on r232 and just tried to get working Data with no avail.

Here are my observations running image #237 ( devel-proposed/ubuntu ) on mako.

First, as Alfonso pointed out in comment #6, there are some new devices that appear when running wily vs. vivid.

Here's a diff of the output of 'ip addr' on rc vs. devel-proposed:

 espy@shrike:% diff mako-vivid-ip-devices.out mako-wily-ip-devices.out
24,27c24,28
< 24: rmnet_usb0: <> mtu 2000 qdisc noop state DOWN group default qlen 1000
< 25: rmnet_usb1: <> mtu 2000 qdisc noop state DOWN group default qlen 1000
< 26: rmnet_usb2: <> mtu 2000 qdisc noop state DOWN group default qlen 1000
< 27: rmnet_usb3: <> mtu 2000 qdisc noop state DOWN group default qlen 1000
---
> 24: enx0af53fef2539: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2000 qdisc pfifo_fast state UNKNOWN group default qlen 1000
> 25: enxda4f6c1d2a6d: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2000 qdisc pfifo_fast state UNKNOWN group default qlen 1000
> 26: enxea43c82d167a: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2000 qdisc pfifo_fast state UNKNOWN group default qlen 1000
> 27: enx66b76e767656: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2000 qdisc pfifo_fast state UNKNOWN group default qlen 1000

Turns out this is due to the recent landing in wily of "stateless persistant network interface names", by Martin Pitt. See:

https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038786.html

As these devices are owned by rild, we need to investigate how to exclude these devices from being re-named. Also our current version of NetworkManager uses hard-coded paths in NMManager to ignore these devices, we need to prevent the re-name for the time-being. Note, we also need to come up with a more generic mechanism to keep network-manager from touching rild-owned devices.

Next clue... I disabled network-manager via a manual upstart override file, and rebooted. When I try to activate a GPRS context directly via the ofono script ( /usr/share/ofono/scripts ) 'activate-context', an error is returned:

Error activating /ril_0/context1: org.ofono.Error.Failed: Operation failed

At the same time, I see the following syslog error messages from ofono:

Jun 26 15:46:39 ofonod[1518]: ril_setup_data_call_cb: no DNS in context of type 1
Jun 26 15:46:39 ofonod[1518]: ril_gprs_context_deactivate_primary: couldn't remove call_list listener for apn: nxtgenphone.
Jun 26 15:46:39 ofonod[1518]: ril_deactivate_data_call_cb: reply failure for apn: nxtgenphone - GENERIC_FAILURE

Here's the corresponding ril trace:

ofonod[12095]: [0,0143]> RIL_REQUEST_SETUP_DATA_CALL (13,0,nxtgenphone,,,0,IP)
ofonod[12095]: [0,0143]< RIL_REQUEST_SETUP_DATA_CALL {version=9,num=1 [status=65535,retry=-1,cid=0,active=0,type=,ifname=,address=,dns=,gateways=]}

So the DATA_CALL is clearly failing.

And yet another clue from the logcat radio log whenever I try to activate a context:

E/RILQ ( 1160): (0/20): [main] qcril_data_request_setup_data_call: unable to get dsi hndl
E/RILQ ( 1160): (0/20): [main] qcril_data_request_setup_data_call: qcril_data_request_setup_data_call: EXIT with FAILURE
E/RILQ ( 1160): (0/20): [main] qcril_data_request_deactivate_data_call: no valid CID [-1] match found
E/RILQ ( 1160): (0/20): [main] qcril_data_response_generic_failure: qcril_data_response_generic_failure: ENTRY
E/RILQ ( 1160): (0/20): [main] qcril_data_response_generic_failure: qcril_data_response_generic_failure: EXIT
E/RILQ ( 1160): (0/20): [main] qcril_data_request_deactivate_data_call: qcril_data_request_deact_data_call: EXIT with err

This might be related to the following kernel error in the syslog:

Jun 26 15:42:46 ubuntu-phablet kernel: [ 13.529528] mipi_dsi_controller_cfg: DSI status=8 failed

My bet is that the data failure is related to the "unable to get dsi hndl" error, not the devices being re-named. The next thing we should try and reverting the device-rename to see allows data calls to be made.

Finally in reference to voice and SMS, these are working at the low-level. The modem registers properly, and I'm able to dial out via the dial-number script and send an SMS via the send-sms script.

The dialer-app shows "No Network", so my guess is that there's a telephony-service problem that needs to be resolved. If someone could file a separate bug for against 'telephony-service' stating the neither the dialer-app nor messaging-app can see the network, that would be appreciated.

Finally, one last comment... I'm not sure what the state of systemd is on our wily-based images. I did notice that changes to the ofono.override file weren't being picked up, yet a network-manager manual override file did seem to work...

While testing on mako/rc, I can confirm that the rmnet_usbX devices are those configured for data calls over the cellular connection, and that these are the devices being re-named. As mentioned above, we should try reverting the new USB re-naming scheme first...

Image r234 has no working Data, and the phone application says "No Network" but the signal bars show full bars. If anyone needs me to run some scripts let me know.

@Arron

Thanks, but I think we have a handle on what's broken...

The "No network"/no calls issue on dialer-app can be resolved by manually installing telepathy-ofono-ril-mc-plugin package.
It should be automatically pulled by the metapackage, but the MR adding it to the metapackage didn't land yet on wily:
https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_add_telepathy-ofono-ril-mc-plugin/+merge/259891

I will ask Timo to take care of it.
Thanks.

This was discussed a while ago, see https://lists.ubuntu.com/archives/ubuntu-devel/2015-June/038777.html for reference and /usr/share/doc/udev/README.Debian.gz for a documentation on current network device naming.

If there is a reason to exclude rmnet_* from that schema, i. e. we have a place which hardcodes the device names instead of selecting them by properties, you can add a file /lib/systemd/network/00-rmnet-kernel.link or /etc/systemd/network/00-rmnet-kernel.link with

---------- 8< -----------
[Match]
OriginalName=rmnet_*

[Link]
NamePolicy=kernel
MACAddressPolicy=persistent
---------- 8< -----------

I'll change /lib/systemd/network/01-mac-for-usb.link to 50-* in our udev package to make it a bit easier to add exceptions with lexicographically earlier rule names.

@Martin

I was aware of the change, but hadn't considered the possible effects on rild at the time.

If possible, I'd rather disable the re-naming whole-sale for touch images. Adding devices to a black-list won't scale... and would require us to add configuration files to the device tarballs that get copied to the Ubuntu filesystem. If this is the only option available to us, then c'est la vie, but its a less than ideal...

Right, that was my concern -- the ofono package could ship that /lib/systemd/network/00-rmnet-kernel.link without the need for any overrides during image build or device tarballs. You would need the latter if you want to disable persistant names wholesale.

If you want to disable it wholesale, then either boot with "net.ifnames=0" on the kernel command line, or create an empty /etc/udev/rules.d/80-net-setup-link.rules to override the rules in /lib/udev/rules.d/.

Hmm, glad to find this thread. I've got probably the same issuhe here with Nexus 7: https://bugs.launchpad.net/ubuntu/+source/nuntium/+bug/1469496

I'm also affected by this bug. Is there any temporary workaround? The phone is hardly usable if it's not possible to make calls or send sms. Or is a fix going to be released in the near future? Thank you!

@simon: You could follow what pitti proposed above:

1. Remount roofs rw
$ sudo mount -o remount,rw /
2. Create an /etc/udev/rules.d/80-net-setup-link.rules file on the device
$ sudo touch /etc/udev/rules.d/80-net-setup-link.rules
3. Reboot
$ sudo reboot

That will give you mobile connectivity back until a fix is out.

This fix was implemented per comment #19 by adding the file:

/etc/systemd/network/00-rmnet-kernel.link

to our images via the lxc-android-config package ( version 0.228 ) on wily.

See attached file for the details.

Changing Status to FixReleased as this has landed in wily.

#25 nor #19 does fix the issue that you cant receive/send calls/messages.

If cellular data/wifi isnt connected, its sill an issue!
So we have a weird dependcy that we either need wifi/cellular?!

You cant force people who use prepaid systems to cost them alot of money. If they dont enable cellular data they cant use the basic functions of the phone!

Im on OTA5 @ mako with the patch applied manually.

Wrong bug, creating a new one...