NM does not retry opening mobile data on reboot

[Alfonso Sanchez-Beato]

In case NM has failed to open any mobile data context, it will not re-try when rebooting the phone.

This happened with a pre-paid SIM with no credit: opening a data context for it obviously failed. After adding credit to the SIM, I followed the instructions from the operator to reboot the phone to get data. However, after rebooting I had no mobile data. Taking a look to system settings, cellular data was set to "Off" and I was able to revert the situation marking the "2G/3G/4G" option. Make NM retry the list of contexts in case no context was ever active on previous boot would make life easier for the user.

[Tony Espy (awe)]

Please add version info for NetworkManager and an image # as this is a phone-specific bug, not a desktop bug.

Can you also please add a condensed version of the syslog containing the NetworkManager messages and ofono's gprs settings file?

Also, if you can come up with an easy set of steps to reproduce that would be helpful. I think it might be possible to simulate this by using a broken APN ( ie. an APN with an invalid name ), then stopping network-manager, fixing the APN and rebooting.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

This happened for touch image #149, with network-manager version 0.9.8.8-0ubuntu23 .

syslog for a simulated case where the APN name is wrong (APN err.airtelwap.es), then ofono is stopped, the APN corrected (airtelwap.es) and the phone rebooted is attached. The result is that no context is activated. However, I would not say that this is exactly the same case as the one in the description, as in this case after restarting system settings has data set as "2G/3G/4G" instead of "Off". Probably the APN name change makes NM behave slightly different.

[Tony Espy (awe)]

So, in the case of an incorrect APN, it's my assumption that the APN Editor will *always* notify NM after adding a new custom Internet context ( ie. because fixing isn't yet allowed ). We should verify this with the System Settings team.

I *think* you should be able to re-create the first scenario by adding a test hook env variable that causes a failure to be returned to a SETUP_DATA_CALL. Then clear the variable and reboot. I'll give this a try.

[Tony Espy (awe)]

So I re-tested your incorrect APN scenario and another that was as close as I could get to your original scenario. Note, I didn't check the mobile data settings in any of these tests.

Here's what I did on mako, running rtm image #26 plus a modified version of the latest ofono from the rtm.

I stopped ofono & NM, then edited ofono's gprs settings file for the current SIM ( more on that later ) and appended ".foo" to each of the context "AccessPointName" values. I also deleted /var/lib/NetworkManager/timestamps and then rebooted.

NM tries context1 ( "ATT PHONE" ) four times ( each failing ), then context2 ( "ATT WAP" ) which also fails. NM marks each connection as "Invalid".

Note, I also discovered that NM tries to activate other contexts found in previous SIM card directories under /var/lib/ofono. I will open another bug for this problem.

Next, I stopped ofono and NM again, edit the gprs file, and correct the AccessPointName values and reboot. After rebooting, NM seems to properly find the correct context and activates it.

I also tried to simulate your first scenario, but checking an environment variable ( "OFONO_RIL_DATA_FAIL" ) in rilmodem/gprs-context.c in the callback that handles the data reply. If the env var is set, I treat it like a FAILED reply from ril. Again I rebooted and watched NM fail to connect either context and mark both Invalid. After removing the env var from the upstart job, I rebooted and again NM comes up and properly activates the correct context.

I will try to reproduce on krillin next.

[Tony Espy (awe)]

Here's the patch to to cause DATA_CALL failures:

=== modified file 'drivers/rilmodem/gprs-context.c'
--- drivers/rilmodem/gprs-context.c 2014-07-30 07:30:49 +0000
+++ drivers/rilmodem/gprs-context.c 2014-09-10 20:34:46 +0000
@@ -144,7 +144,12 @@

  DBG("*gc: %p", gc);

- if (message->error != RIL_E_SUCCESS) {
+ /*
+ * TODO: it would be nice to be able to control the data-fail via
+ * a property instead of an env var
+ */
+
+ if (message->error != RIL_E_SUCCESS || getenv("OFONO_RIL_DATA_FAIL")) {
   ofono_error("%s: setup data call failed for apn: %s - %s",
     __func__, gcd->apn,
     ril_error_to_string(message->error));

[Tony Espy (awe)]

Note, I tried the same scenarios on krillin running rtm image #17.

In both cases, I see the same behavior, that NM properly re-connects the connection after the problem has been resolved. Also, in the case where I used the patched ofono, I checked and there seemed to be no effect on the Mobile Data system setting preference.

If you can reproduce this again, please include the relevant Network Manager messages from syslog. NM attempts to connect to a context four times, before marking it Invalid for the session, and moving on to the next connection. Marking the connection Invalid is not persistent across reboots.

[Alfonso Sanchez-Beato (alfonsosanchezbeato)]

My guess here is that what I saw was an instance of the generic problem that NM seems to have some times creating connections, which is probably related to not detecting the creation of the ofono's ConnectionManager interface.

As I usually have two SIMs around, this is maybe easier for me to reproduce.

[Tony Espy (awe)]

OK, please let me know if you're able to reproduce this with multiple SIMs.

Note that bug #1350332 ( which is private ) describes a problem with mobile-data not being re-established for the 2nd slot after FlightMode is disabled. I'm pretty sure this is a generic problem on krillin which affects both slots and will open a new network-manager bug after doing a bit more testing.

Please try and reproduce this with multiple SIMs, and if you cannot, please change the Status to Invalid.

[Bryan Quigley (bryanquigley)]

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).