1134644 - Tethering do not work on Orange F SIM card when "dun" APN is defined

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[:gerard-majax]

I cannot get tethering to work with Orange F nano SIM provided by Mozilla.
After digging, it turns out we have a Tethering APN defined in Gaia.

STR:
 0. Make sure you have an Orange F SIM card, and a "dun"-type tethering APN defined in Settings.
 1. Enable WiFi thethering

Expected:
 Tethering works.

Actual:
 It fails.

I could see we go through https://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/NetworkManager.js#1101, i.e. |dun.state != Ci.nsINetworkInterface.NETWORK_STATE_CONNECTED|. We indeed have dun.state at 3 (NETWORK_STATE_DISCONNECTED).

This was reproduced either with data connection enabled or disabled. Enabling NetworkManager.js logging showed that it was somehow not able to properly mount the DUN APN, because of triggering |onDunConnectTimerTimeout|.

Deleting the "dun"-type APN defined in the Tethering section of Settings makes the feature working properly.

Comment 1

[:gerard-majax]

Jessica, you did some refactoring recently around this, could it be related?

Comment 2

[Jessica Jong [:jessica] (inactive)]

(In reply to Alexandre LISSY :gerard-majax from comment #1)
> Jessica, you did some refactoring recently around this, could it be related?

Yes, it could be related. In bug 1115299, we change it to: if there is dun apn type (dun network registered), then usb/wifi tethering must use that apn. In your case, it looks like your dun apn does not work, hence tethering fails.

May I know your mcc/mnc, including if it's mvno? Or event better if you could upload logs with radio log enabled. Let's check if there is any problem with the apn. Thanks.

Comment 3

[:gerard-majax]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #2)
> (In reply to Alexandre LISSY :gerard-majax from comment #1)
> > Jessica, you did some refactoring recently around this, could it be related?
> 
> Yes, it could be related. In bug 1115299, we change it to: if there is dun
> apn type (dun network registered), then usb/wifi tethering must use that
> apn. In your case, it looks like your dun apn does not work, hence tethering
> fails.
> 
> May I know your mcc/mnc, including if it's mvno? Or event better if you
> could upload logs with radio log enabled. Let's check if there is any
> problem with the apn. Thanks.

Orange F 20801, no MVNO. Regarding the DUN APN, I have never saw the data connection getting triggered. I'll have a look at the logs, but the APN name is not the same as the one used for the data connection (orange VS orange.fr).

Comment 4

[:gerard-majax]

Ok, that's pretty obvious:
> 02-24 08:40:43.899  1694  1694 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"radioTech":11,"apn":"orange.fr","user":"orange","passwd":"orange","chappap":0,"pdptype":"IP","rilMessageClientId":0,"rilMessageType":"datacallerror","rilRequestType":27,"rilRequestError":0,"status":33,"suggestedRetryTime":-1,"errorMsg":"ServiceOptionNotSubscribedError"}

Then I would say we have two issues here: improper error feedback to the user (how am I supposed to discover the root cause of this error ?), providing a default configuration that has regressed from working to non working.

Comment 5

[Jessica Jong [:jessica] (inactive)]

Because now gaia uses moz settings to enable/disable tethering, it is hard to let gaia/user know the actual result. That is why we are planning to use webapis [1] instead of moz settings. Wifi hotpot through webapi is ready but usb tethering part is not implemented yet.

About providing a default configuration, some carriers force users to use dun apn while tethering due to billing issues. So, if 'tethering.dun.required' is set, we should not fallback to use other data call. In your case, we force to use dun because a dun apn is available, maybe we could fallback to use default data call here. We can have a discussion about this.
One more thing, the 'orange.fr' dun apn was added to the database recently in bug 1112048.


[1] https://dxr.mozilla.org/mozilla-central/source/dom/webidl/MozTetheringManager.webidl

Comment 6

[:gerard-majax]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #5)

[...]

> About providing a default configuration, some carriers force users to use
> dun apn while tethering due to billing issues. So, if
> 'tethering.dun.required' is set, we should not fallback to use other data
> call. In your case, we force to use dun because a dun apn is available,
> maybe we could fallback to use default data call here. We can have a
> discussion about this.

I don't think we need a discussion here. Introducing the dun type is fine, but if that's breaking silently for users then I call this a very bad regression and the fallback should be done asap.

Comment 7

[Jessica Jong [:jessica] (inactive)]

(In reply to Alexandre LISSY :gerard-majax from comment #6)
> (In reply to Jessica Jong [:jjong] [:jessica] from comment #5)
> 
> [...]
> 
> > About providing a default configuration, some carriers force users to use
> > dun apn while tethering due to billing issues. So, if
> > 'tethering.dun.required' is set, we should not fallback to use other data
> > call. In your case, we force to use dun because a dun apn is available,
> > maybe we could fallback to use default data call here. We can have a
> > discussion about this.
> 
> I don't think we need a discussion here. Introducing the dun type is fine,
> but if that's breaking silently for users then I call this a very bad
> regression and the fallback should be done asap.

You're right, I'll take care of this.

Comment 8

[Jessica Jong [:jessica] (inactive)]

Attachment: patch, v1.

Introduce CONFIG_DUN_PREFERRED, this config is set when "ro.tethering.dun_required" is NOT SET but a dun apn is registered. With this config, we'll fallback to other connections when dun is not available. However, NetworkManager does not know about data connection setup failures, so it fallbacks after dun connection times out.


This patch is created based on Bug 1109479.

Comment 9

[Jessica Jong [:jessica] (inactive)]

Comment on attachment 8572373 [details] [diff] [review]
patch, v1.

Edgar, may I have your review? Thank you.

Comment 10

[Edgar Chen [:edgar]]

Comment on attachment 8572373 [details] [diff] [review]
patch, v1.

Review of attachment 8572373 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/system/gonk/TetheringService.js
@@ +352,5 @@
>      this.tetheringSettings[SETTINGS_WIFI_DHCPSERVER_ENDIP]   = DEFAULT_WIFI_DHCPSERVER_ENDIP;
>  
>      this.tetheringSettings[SETTINGS_DUN_REQUIRED] =
> +      libcutils.property_get("ro.tethering.dun_required") === "1" ?
> +      CONFIG_DUN_REQUIRED : CONFIG_DUN_NOT_SET;

Nit: Indentation.

@@ +521,5 @@
> +            return;
> +          }
> +          // Fallback to use current active network.
> +          debug("Dun connection failed, fallback to active or mobile network.");
> +          network = gNetworkManager.active ? gNetworkManager.active :

Nit: network = gNetworkManager.active || ...;

And looks like it could be possible to fallback to use an unexpected network, e.g. MMS, because the |active| could be a "secondary" APN.

Comment 11

[Jessica Jong [:jessica] (inactive)]

(In reply to Edgar Chen [:edgar][:echen] (OOO 3/21~4/6) from comment #10)
> Comment on attachment 8572373 [details] [diff] [review]
> patch, v1.
> 
> Review of attachment 8572373 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/system/gonk/TetheringService.js
> @@ +352,5 @@
> >      this.tetheringSettings[SETTINGS_WIFI_DHCPSERVER_ENDIP]   = DEFAULT_WIFI_DHCPSERVER_ENDIP;
> >  
> >      this.tetheringSettings[SETTINGS_DUN_REQUIRED] =
> > +      libcutils.property_get("ro.tethering.dun_required") === "1" ?
> > +      CONFIG_DUN_REQUIRED : CONFIG_DUN_NOT_SET;
> 
> Nit: Indentation.
> 
> @@ +521,5 @@
> > +            return;
> > +          }
> > +          // Fallback to use current active network.
> > +          debug("Dun connection failed, fallback to active or mobile network.");
> > +          network = gNetworkManager.active ? gNetworkManager.active :
> 
> Nit: network = gNetworkManager.active || ...;
> 
> And looks like it could be possible to fallback to use an unexpected
> network, e.g. MMS, because the |active| could be a "secondary" APN.

You are totally right, we need to fix other tethering parts as well.
But I'm wondering, should NetworkManager's active be set only for default connections (e.g. wifi or default data)? In nsINetworkManager.idl, the comment for 'active' is 'The network interface handling all data traffic'.

Comment 12

[Edgar Chen [:edgar]]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #11)
> (In reply to Edgar Chen [:edgar][:echen] (OOO 3/21~4/6) from comment #10)
> > Comment on attachment 8572373 [details] [diff] [review]
> > patch, v1.
> > 
> > Review of attachment 8572373 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > ::: dom/system/gonk/TetheringService.js
> > @@ +352,5 @@
> > >      this.tetheringSettings[SETTINGS_WIFI_DHCPSERVER_ENDIP]   = DEFAULT_WIFI_DHCPSERVER_ENDIP;
> > >  
> > >      this.tetheringSettings[SETTINGS_DUN_REQUIRED] =
> > > +      libcutils.property_get("ro.tethering.dun_required") === "1" ?
> > > +      CONFIG_DUN_REQUIRED : CONFIG_DUN_NOT_SET;
> > 
> > Nit: Indentation.
> > 
> > @@ +521,5 @@
> > > +            return;
> > > +          }
> > > +          // Fallback to use current active network.
> > > +          debug("Dun connection failed, fallback to active or mobile network.");
> > > +          network = gNetworkManager.active ? gNetworkManager.active :
> > 
> > Nit: network = gNetworkManager.active || ...;
> > 
> > And looks like it could be possible to fallback to use an unexpected
> > network, e.g. MMS, because the |active| could be a "secondary" APN.
> 
> You are totally right, we need to fix other tethering parts as well.
> But I'm wondering, should NetworkManager's active be set only for default
> connections (e.g. wifi or default data)? In nsINetworkManager.idl, the
> comment for 'active' is 'The network interface handling all data traffic'.

Yup, 'active' should be set for default connections only, but some how NetworkManager doesn't set it correctly :(. We should also fix that as well.

Comment 13

[Jessica Jong [:jessica] (inactive)]

(In reply to Edgar Chen [:edgar][:echen] (OOO 3/21~4/6) from comment #12)
> (In reply to Jessica Jong [:jjong] [:jessica] from comment #11)
> > (In reply to Edgar Chen [:edgar][:echen] (OOO 3/21~4/6) from comment #10)
> > > Comment on attachment 8572373 [details] [diff] [review]
> > > patch, v1.
> > > 
> > > Review of attachment 8572373 [details] [diff] [review]:
> > > -----------------------------------------------------------------
> > > 
> > > ::: dom/system/gonk/TetheringService.js
> > > @@ +352,5 @@
> > > >      this.tetheringSettings[SETTINGS_WIFI_DHCPSERVER_ENDIP]   = DEFAULT_WIFI_DHCPSERVER_ENDIP;
> > > >  
> > > >      this.tetheringSettings[SETTINGS_DUN_REQUIRED] =
> > > > +      libcutils.property_get("ro.tethering.dun_required") === "1" ?
> > > > +      CONFIG_DUN_REQUIRED : CONFIG_DUN_NOT_SET;
> > > 
> > > Nit: Indentation.
> > > 
> > > @@ +521,5 @@
> > > > +            return;
> > > > +          }
> > > > +          // Fallback to use current active network.
> > > > +          debug("Dun connection failed, fallback to active or mobile network.");
> > > > +          network = gNetworkManager.active ? gNetworkManager.active :
> > > 
> > > Nit: network = gNetworkManager.active || ...;
> > > 
> > > And looks like it could be possible to fallback to use an unexpected
> > > network, e.g. MMS, because the |active| could be a "secondary" APN.
> > 
> > You are totally right, we need to fix other tethering parts as well.
> > But I'm wondering, should NetworkManager's active be set only for default
> > connections (e.g. wifi or default data)? In nsINetworkManager.idl, the
> > comment for 'active' is 'The network interface handling all data traffic'.
> 
> Yup, 'active' should be set for default connections only, but some how
> NetworkManager doesn't set it correctly :(. We should also fix that as well.

Filed bug 1143984 for this.

Comment 14

[:gerard-majax]

[Blocking Requested - why for this release]: bad regression, hard to diagnose for people.

Sorry for the late notification, but this was filled quite some time ago already, I expected it would be fixed quickly. Checking bug 1115299, I just noticed this was landed on 2.2 also.

So we are indeed breaking tethering for some users, and it's very hard to diagnose why it's broken.

Comment 15

[Jessica Jong [:jessica] (inactive)]

(In reply to Alexandre LISSY :gerard-majax from comment #14)
> [Blocking Requested - why for this release]: bad regression, hard to
> diagnose for people.
> 
> Sorry for the late notification, but this was filled quite some time ago
> already, I expected it would be fixed quickly. Checking bug 1115299, I just
> noticed this was landed on 2.2 also.
> 
> So we are indeed breaking tethering for some users, and it's very hard to
> diagnose why it's broken.

Bug 1115299 was not landed on v2.2, v2.2 was branched on 1/12 [1]. It's just the 'Target Milestone' that makes it confusing.

This bug depends on Bug 1143984, which is waiting for bug 992772. We can still land this first, but there is a possibility that tethering fallsback to mms as external interface, which won't work cause there is no default route. I can discuss with the reviewer when he is back from PTO.

[1] https://wiki.mozilla.org/Release_Management/FirefoxOS/2_2_Schedule

Comment 16

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

[Blocking Requested - why for this release]:
Per comment 15 I believe it's not affected in v2.2, so changing the nom to 3.0?
Waiting for QAWanted to reconfirm.

Comment 17

[Johan Lorenzo [:jlorenzo]]

I couldn't reproduce the issue on master[1]. I used 2 different Orange F SIM cards with either this tethering configuration[2] or no tethering config.

I managed to browse a web page through the tethering each time.

I checked with :gerard-majax, he still reproduces the problem on the Aries device.

Guillaume, :gerard-majax and I used the SIM cards bought by Mozilla. Do you know what could differ between the two?

Clearing qawanted as the branch check couldn't be done with the current set up.

[1] Build ID               20150409010203
Gaia Revision          5dfd0460eb6e616205154b0d219aa5123bf1abb3
Gaia Date              2015-04-08 18:08:18
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/8f57f60ee58a
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150409.043625
Firmware Date          Thu Apr  9 04:36:34 EDT 2015
Bootloader             L1TC000118D0

[2] APN: orange.fr
Identifier: orange
Authentication: None
APN type: dun
Protocol: Not defined
Roaming protocol: Not defined

Comment 18

[Guillaume Canavaggio [:guiom]]

jlorenzo: I was wondering if gerard_majax was using a prepaid nano SIM card or a Orange Business one.

Comment 19

[:gerard-majax]

(In reply to Guillaume Canavaggio [:guiom] from comment #18)
> jlorenzo: I was wondering if gerard_majax was using a prepaid nano SIM card
> or a Orange Business one.

That's the one you gave me, a nano SIM. I think it's a prepaid one.

Comment 20

[Johan Lorenzo [:jlorenzo]]

I got gerard-majax's SIM. I repro'd the issue on 3.0[1] but not on 2.2[2].

[1] Build ID               20150410010202
Gaia Revision          e768af6558957ddb0f6a9ce579ea41c3e3d0b203
Gaia Date              2015-04-10 00:05:39
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/fec90cbfbaad
Gecko Version          40.0a1
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150410.043845
Firmware Date          Fri Apr 10 04:38:56 EDT 2015
Bootloader             L1TC000118D0

[2] Build ID               20150414002504
Gaia Revision          73645b097720f3ca594a14d288b87d3885d7fc9d
Gaia Date              2015-04-13 19:30:36
Gecko Revision         https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/85ea1be9ac7d
Gecko Version          37.0
Device Name            flame
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.cltbld.20150414.042143
Firmware Date          Tue Apr 14 04:21:54 EDT 2015
Bootloader             L1TC000118D0

Comment 21

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: regression

Comment 22

[Doug Sherk (:drs) (inactive)]

Bhavana, this should block Spark.

Comment 23

[Jessica Jong [:jessica] (inactive)]

Hi jlorenzo, Bug 1159132 has landed, which reverts Bug 1115299 partially, so this issue should not exist anymore. Could you help test it again so we can close this bug? Thanks.

Comment 24

[:gerard-majax]

I'll try to update my Z3 device that has the Orange SIM card that exposes the issues and test again.

Comment 25

[Johan Lorenzo [:jlorenzo]]

:gerard-majax, Feel free to drop your SIM at my desk, if you wish.

Comment 26

[:gerard-majax]

I have updated my Z3 which has the Orange SIM card, resetted the APNs and I do have tethering working without having to manually remove the "dun" APN. So it was indeed fixed by bug 1159132.