Closed Bug 980375 Opened 10 years ago Closed 10 years ago

[Cellular Data] Cant get Cellular Data Connections to work when Using TMobile SIM

Categories

(Firefox OS Graveyard :: RIL, defect)

x86
macOS
defect
Not set
normal

Tracking

(blocking-b2g:1.4+, b2g-v1.4 fixed)

VERIFIED FIXED
1.4 S3 (14mar)
blocking-b2g 1.4+
Tracking Status
b2g-v1.4 --- fixed

People

(Reporter: retornam, Assigned: vicamo)

References

Details

(Keywords: regression, smoketest)

Attachments

(2 files)

Hamachi
Model : qcom
Software: Boot2gecko 1.4.0.0-pre-release
Build Identifier 20140306040204
Git Commit info 2014-03-05 18:41:06 (9cb35e70)

Hi,we noticed today that cellular data connections were not working when we used TMobile SIMs -from running Gaia-UI tests- even though the connection information was correct and cellular data was enabled on the test Hamachi phone. To be sure that the problem was not due to the SIM card, I inserted the same SIM card into A Google Galaxy Nexus phone with wifi off. I was able to get online successfully using cellular data on the Galaxy Nexus. 

Please needinfo me if you need me to collect logs from the phone or help debug the issue.
I noticed a similar issue (no cellular data at all, with a T-Mobile SIM) after updating a Hamachi yesterday with a new self-built user build of master; I didn't have the same problem with a master build from the day before.

The revisions I'd updated to were Gecko 46a7d980050ade443e061f2be9419b0a873f2958 and gaia f43d1f3997dd371b96e1ef8c0f5437a1a9b5b58a.  The old (working) Gecko revision was d574219c44f75c9dfb007274e9de0479ef51020a, but I don't have the old (working) gaia revision.
blocking-b2g: --- → 1.4?
Keywords: qaurgent
QA Contact: mvaughan
Attached file nodata.txt
Adding a logcat. Confirming that data does work using the same build with an AT&T card.
The following regression window was found using b2g-inbound builds:

- Last Working -
Device: Buri ENG v1.4 MOZ RIL
BuildID: 20140304172624
Gaia: dbc9a1b45f2ecb37bbde7d216bb3b83e2985d5a5
Gecko: 833431df6ec5
Version: 30.0a1
Firmware Version: V1.2-device.cfg

- First Broken -
Device: Buri ENG v1.4 MOZ RIL
BuildID: 20140304183823
Gaia: dbc9a1b45f2ecb37bbde7d216bb3b83e2985d5a5
Gecko: f8cc200ee6ec
Version: 30.0a1
Firmware Version: V1.2-device.cfg

Push Log: http://hg.mozilla.org/integration/b2g-inbound/pushloghtml?fromchange=833431df6ec5&tochange=f8cc200ee6ec
bug 957917 broke this.
Blocks: 957917
Bug 957917 has been backed out and new nightlies off m-c have been triggered. They should be ready in ~2h.

https://hg.mozilla.org/mozilla-central/rev/8095b7dd8f58
Assignee: nobody → vyang
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4 S3 (14mar)
Here's a logcat from T-Mobile's network with:

 * mozilla-central as of right before the backout (plus my local patches), and gaia from about the same time (slightly later, I think)

 * DEBUG_ALL turned on at the top of ril_consts.js

 * additional debugging code here:
https://hg.mozilla.org/mozilla-central/file/901717199390/dom/system/gonk/RadioInterfaceLayer.js#l4521
to print pdptype before and after the if (marked as "dbaron RIL debug")

(It shows T-Mobile's network is saying to use IPV6.)
Attachment #8387231 - Attachment mime type: text/x-vhdl → text/plain
Thanks for David's log which provides valuable information.

The apn setting of "fast.t-mobile" indicates "IPv6" as protocol type. Please see "gaia/shared/resource/apn.json". Before bug 957917, RIL ignores the specified protocol of the setting and use "IP (ipv4)" for every case. However, this is not that right and we tried to improve that. So, after bug 957917, RIL reads the "protocol" of apn settings to determine the pdptype is required for the data call. As "fast.t-mobile" requires IPv6, RIL tries to setup data call according to the setting that is nothing wrong.

So, two plausible guesses for this issue: either carrier "fast.t-mobile" or modem doesn't really support IPv6 that leads to this issue. I checked android's commit and it's T-mobile's requirement to add "IPv6" into apn database so 1) doesn't stand. Regarding 2), I am wondering if the modem of these phones (Hamachi and Buri) support IPv6 already. Any idea, Ken?
Flags: needinfo?(kchang)
Vance, could you please help to make sure if the modem of Buri/Hamachi support IPV6? Thanks.

Furthermore, I think we should provide a property for enabling IPv6. Some devices may not support IPV6 in their modem.
Flags: needinfo?(kchang) → needinfo?(vchen)
(In reply to Ken Chang[:ken] from comment #8)
> Vance, could you please help to make sure if the modem of Buri/Hamachi
> support IPV6? Thanks.
> 
> Furthermore, I think we should provide a property for enabling IPv6. Some
> devices may not support IPV6 in their modem.

Hi Ken, I just have a quick chat with TCL SPM Jack, he mentioned that they once modified some configuration for ipv6 based on Telefonica's suggestion, and the verification result from TEF is OK. So Buri/Hamachi should work fine with IPV6 enable. 

May i ask what base image of Buri/Hamachi you use to run the test?

ni Jack as well to provide information regarding the configuration modification for ipv6

Thanks

Vance
Flags: needinfo?(liuyongming)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #9)
> May i ask what base image of Buri/Hamachi you use to run the test?
raymond, may you provide this information? Thanks.
Flags: needinfo?(mozbugs.retornam)
Some updates:

According to the bug#960974, looks like in the current Buri/Hamachi kernel image some of the ipv6 relevant compile options are not enable correctly. I already ask TCL to submit a SR to QCT to check how to fully enable ipv6 in the 7x27a platform.

Dear Ken/Hsin-Yi, please let me know if you have any comments

Thanks

Vance
Flags: needinfo?(vchen)
Flags: needinfo?(liuyongming)
Flags: needinfo?(kchang)
Flags: needinfo?(htsai)
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #11)
> Dear Ken/Hsin-Yi, please let me know if you have any comments
We can just think the buri/Hamachi doesn't support IPV6. RIL will add a mechanism for devices not supporting IPV6.
Flags: needinfo?(mozbugs.retornam)
Flags: needinfo?(kchang)
(In reply to Ken Chang[:ken] from comment #12)
> (In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #11)
> > Dear Ken/Hsin-Yi, please let me know if you have any comments
> We can just think the buri/Hamachi doesn't support IPV6. RIL will add a
> mechanism for devices not supporting IPV6.

Agree with Ken. Let us have more protection on bug 957917.
Flags: needinfo?(htsai)
blocking-b2g: 1.4? → 1.4+
(In reply to Hsin-Yi Tsai  [:hsinyi] from comment #13)
> (In reply to Ken Chang[:ken] from comment #12)
> > (In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #11)
> > > Dear Ken/Hsin-Yi, please let me know if you have any comments
> > We can just think the buri/Hamachi doesn't support IPV6. RIL will add a
> > mechanism for devices not supporting IPV6.
> 
> Agree with Ken. Let us have more protection on bug 957917.

Ok in that case, I wont need to ask TCL to provide a kernel image that fully enable ipv6

Thanks

Vance
This bug can be Verified Fixed. 
Cellular data connections works when using TMobile SIMs.

BuildID: 20140307040203
Gaia: 04eb7996543f114133d1367f834a4d88b68c60ac
Gecko: b0e7f63c2138
Version: 30.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: