795415 - mobile data no longer works in 9/28 build

Status: RESOLVED INVALID

(Firefox OS Graveyard :: General, defect)

Description

[Dietrich Ayala (:dietrich)]

worked yesterday.

gaia issue. https://github.com/mozilla-b2g/gaia/issues/5437

Comment 1

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

I think it might be a firmware update issue.  Today's build should include the Kernel 9 update.  

Yesterday's build did not.  I flashed yesterday's build on my device and I can't get mobile data to work anymore.

Comment 2

[Jason Smith [:jsmith]]

Andrew - This breaks a smoke test. Can you help us find an owner for this?

Comment 3

[Andrew Overholt [:overholt]]

philikon, can you take a look?

Comment 4

[Tony Chung [:tchung]]

ccing mwu also.  is this related to the kernal 9 update?

Comment 5

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Digging further to try to see where the break is.
I was able to get mobile data to work with this combo:
firmware update 8 + otoro_2012-09-25_ics_eu.zip

used firmware update 9 + otoro 2012-09-25_ics_eu.zip and it does work.  firmware update 9 does seem to make loading of the edge network and apps slower though by several seconds?  Might need to write a new bug on that.

Comment 6

[[:fabrice] Fabrice Desré]

I'm running current gaia tip (d66f92aa69fa8e3a2055fa0f317f6b826a2f1dfb) and mozilla-inbound (443cc572e40f) with a kernel 8. Data connection is working fine.

Comment 7

[Andrew Overholt [:overholt]]

Mobile data works for me with otoro_2012-09-28_ics_us.zip.

Comment 8

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Firmware 9 + 2012-09-26 ics us seems to work.
Firmware 9 + 2012-09-27 ics us does not seem to work.  
Seems like there's a break between 26th and 27th build with Firmware 9?

Comment 9

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Note I am using t-mobile.

Comment 10

[Dietrich Ayala (:dietrich)]

I'm using AT&T.

This is a major dogfooding blocker. Philikon, if you need an AT&T sim to test with, ask Peter Oneill in IT.

Comment 11

[Dietrich Ayala (:dietrich)]

There's definitely a Settings bug. I can fiddle with the UI until choosing medianet populates the APN and hitting OK actually works, which turns on data.

However, Mwu pointed out that something cleared or unset the default APN in the first place, since this used to work just fine with no configuration outside of inserting the SIM card.

Comment 12

[Andrew Overholt [:overholt]]

Is bug #792879 related?

Comment 14

[Tim Guan-tin Chien [:timdream] (please needinfo)]

I can connect to mobile data without problem with kernelupdate9 and latest Gaia & Gecko. I am using a Chungwha Telecom SIM in Taiwan.

The only problem is that I have to manually turn on the mobile data and verify the APN settings, but that's the scope of bug 792879.

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Dietrich Ayala (:dietrich) from comment #11)
> However, Mwu pointed out that something cleared or unset the default APN in
> the first place, since this used to work just fine with no configuration
> outside of inserting the SIM card.

IMO, whatever that "something" is, it's doing the correct thing here. The behavior of the SIM should match the configuration in settings. If settings doesn't provide a default and doesn't even turn on the data, then data shouldn't connect.

Comment 16

[Fabien Cazenave [:kaze]]

(In reply to Dietrich Ayala (:dietrich) from comment #11)
> However, Mwu pointed out that something cleared or unset the default APN in
> the first place, since this used to work just fine with no configuration
> outside of inserting the SIM card.

In the default settings (build/settings.js), `ril.data.enabled' is false and all other `ril.data.*' settings are empty. So if it worked before, it means that AT&T does not require any APN setting to get the data connection working (which is neat!).

As Shian-Yow just told me on IRC, there’s been a recent Gecko change that prevents data connection if `ril.data.apn' is empty:
https://bugzilla.mozilla.org/attachment.cgi?id=664918&action=diff#a/dom/system/gonk/RadioInterfaceLayer.js_sec6

Dietrich, this might be the cause of the regression you mention. Two possible ways to solve it:
 • remove the “empty APN check” that’s been introduced by bug 772747;
 • tweak the Settings app so that if the data connection is enabled and the APN settings are empty, it should first look in the APN database and auto-fill all related settings.

I’m working on the latter atm, I /think/ it should be enough.

Comment 17

[Shian-Yow Wu [:swu]]

Good that the cause has been found!

The empty APN check is needed to prevent further errors in multiple APNs situation, which use APN name to distinguish between different APNs.  Just remove this checking may cause problem when there are multiple APNs.  If we want to allow empty APN name, maybe we can consider allow it only for data APN. 

IMO, the option 2 proposed by Kaze is a good idea.

Comment 18

[Tim Guan-tin Chien [:timdream] (please needinfo)]

kaze, Shianyow, if we go for options 2 in comment 16, that makes this bug RESOLVED INVALID since all fixes should be addressed in bug 792879.

Comment 19

[Fabien Cazenave [:kaze]]

Agreed.