bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

mobile data no longer works in 9/28 build

RESOLVED INVALID

Status

Firefox OS
General
RESOLVED INVALID
6 years ago
6 years ago

People

(Reporter: dietrich, Assigned: philikon)

Tracking

({regression})

unspecified
ARM
Gonk (Firefox OS)
regression

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Reporter)

Description

6 years ago
worked yesterday.

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

Updated

6 years ago
blocking-basecamp: --- → ?
(Reporter)

Updated

6 years ago
OS: Mac OS X → Gonk
Hardware: x86 → ARM
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.
Andrew - This breaks a smoke test. Can you help us find an owner for this?
philikon, can you take a look?
Assignee: nobody → philipp
Keywords: regression

Comment 4

6 years ago
ccing mwu also.  is this related to the kernal 9 update?
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.
I'm running current gaia tip (d66f92aa69fa8e3a2055fa0f317f6b826a2f1dfb) and mozilla-inbound (443cc572e40f) with a kernel 8. Data connection is working fine.
Mobile data works for me with otoro_2012-09-28_ics_us.zip.
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?
Note I am using t-mobile.
blocking-basecamp: ? → +
(Reporter)

Comment 10

6 years ago
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.
(Reporter)

Comment 11

6 years ago
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.
Duplicate of this bug: 796784
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.
(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.
(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

6 years ago
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.
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.
Agreed.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.