Closed
Bug 1171283
Opened 9 years ago
Closed 9 years ago
[Aries][Messaging][MMS] T-Mobile SIM is unable to send an MMS on the Aries device.
Categories
(Firefox OS Graveyard :: RIL, defect)
Tracking
(blocking-b2g:2.5+, b2g-master fixed)
Tracking | Status | |
---|---|---|
b2g-master | --- | fixed |
People
(Reporter: Marty, Assigned: bevis)
References
()
Details
(Keywords: smoketest, Whiteboard: [3.0-Daily-Testing][Spark])
Attachments
(5 files)
Description: The user is unable to send an MMS with a T-Mobile SIM. Attempting to send an MMS message will result in the message being greyed out and displaying "Sending..." endlessly. Note: AT&T SIMs will send MMS messages correctly. Repro Steps: 1) Update a Xperia Z3 Compact (B2G) to 20150603164854 2) Ensure there is a T-Mobile SIM in the device. 3) Open the messages app 4) Compose and send an MMS message. Actual: The MMS does not send. Remains greyed out with the "Sending..." text. Expected: The MMS sends properly. Environmental Variables: Device: Xperia Z3 Compact (B2G) 3.0 (Full Flash) Build ID: 20150603164854 Gaia: ff80db87926a5c2769e158801090465b4ed117fa Gecko: 196d99aabc27 Version: 41.0a1 (3.0) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0 Repro frequency: 10/10 See attached: Logcat, Video (URL) ---------------------------------------------------------------- This issue does NOT occur on Flame 3.0 builds. The MMS sends properly. Environmental Variables: Device: Flame 3.0 (Full Flash) Build ID: 20150603010205 Gaia: 9b7ed13e0dee26b9f16ae5fbc076fa8bd588b256 Gecko: b0a507af2b4a Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67 Version: 41.0a1 (3.0) Firmware Version: v18D-1 User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Reporter | ||
Comment 1•9 years ago
|
||
Link to failed test case: https://moztrap.mozilla.org/manage/case/10742/
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 2•9 years ago
|
||
[Blocking Requested - why for this release]: Functional regression from flame behavior that fails smoke tests.
blocking-b2g: --- → spark?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Assignee | ||
Comment 3•9 years ago
|
||
Hi, We saw similar issue in bug 1169467. Can you help to double confirm 1. Is it always failed for Z3 to send MMS over T-Mobile network no matter what multimedia content you have attached? 2. Can you help to collect main, radio logcat and tcpdump for further clarification by following the instruction in https://github.com/bevis-tseng/Debug_Tools? Thanks!
Component: Gaia::SMS → RIL
Flags: needinfo?(mshuman)
Reporter | ||
Comment 4•9 years ago
|
||
(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #3) > Can you help to double confirm > 1. Is it always failed for Z3 to send MMS over T-Mobile network no matter > what multimedia content you have attached? Yes, I am seeing this happen with .jpg images, .mp3 audio files, and .3gp video files > 2. Can you help to collect main, radio logcat and tcpdump for further > clarification I am attaching the tcpdump and logcats now.
Flags: needinfo?(mshuman)
Reporter | ||
Comment 5•9 years ago
|
||
Reporter | ||
Comment 6•9 years ago
|
||
Reporter | ||
Comment 7•9 years ago
|
||
Assignee | ||
Comment 8•9 years ago
|
||
(In reply to Martin Shuman [:Marty] from comment #5) > Created attachment 8615515 [details] > tcpdump Hi Martin, It seems that you attached the command file instead of the capture.pcap file. Can you help to provide the correct one? Thanks!
Flags: needinfo?(mshuman)
I have a rildebug version that he can use. https://drive.google.com/a/mozilla.com/folderview?id=0B_0LdM1CVycIfmtGbzl3NTRfNTZ6aUpUbDBTM2k5VGNlRUNsWTRyWmJpc09oOVU3MzhxMm8&usp=sharing Marty, please use this build to provide Bevis with the information he requires.
Keywords: qawanted
Keywords: qaurgent
Comment 10•9 years ago
|
||
Here is the requested file. I let it run for about 30 seconds after reproducing the bug so hopefully it caught all information you needed.
Flags: needinfo?(mshuman)
Updated•9 years ago
|
Updated•9 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Assignee | ||
Comment 12•9 years ago
|
||
After checking the logs, the root cause seems the same to what we've seen in bug 1169467 comment 41. We have to figure a way to have a test build with MTU correctly configured for sending MMS to see if we won't get any complaint about "Packet Too Big" anymore.
Comment 13•9 years ago
|
||
netd (KitKat) supports the following command : "interface setmtu <interface> <val>" we could add a path to send this command to netd. However, I wonder why this doesn't happen on Flame...
Assignee | ||
Comment 14•9 years ago
|
||
(In reply to Jessica Jong [:jjong] [:jessica] from comment #13) > netd (KitKat) supports the following command : > "interface setmtu <interface> <val>" > we could add a path to send this command to netd. > > However, I wonder why this doesn't happen on Flame... What I have found so far is that, according to the log/tcpdump in bug 1169467 comment 21 and bug 1169467 comment 22 and the information in [1] , this works on flame because only ipv4 available in Flame device. :( [1] http://www.tcpipguide.com/free/t_ICMPv6PacketTooBigMessages.htm
Comment 15•9 years ago
|
||
(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #14) > (In reply to Jessica Jong [:jjong] [:jessica] from comment #13) > > netd (KitKat) supports the following command : > > "interface setmtu <interface> <val>" > > we could add a path to send this command to netd. > > > > However, I wonder why this doesn't happen on Flame... > > What I have found so far is that, according to the log/tcpdump in bug > 1169467 comment 21 and bug 1169467 comment 22 and the information in [1] , > this works on flame because only ipv4 available in Flame device. :( > > [1] http://www.tcpipguide.com/free/t_ICMPv6PacketTooBigMessages.htm Thanks Bevis, it makes sense then. Path MTU Discovery should be enabled by default for IPv6, but I am not sure if it's working on AOSP. This blogs [1] says that setting 'net.ipv4.tcp_mtu_probing' affects ipv6 connections as well, maybe it worths a try. Another option is to use IPv6 default minimum MTU (1280) for ipv6 connections. [1] https://mellowd.co.uk/ccie/?p=5607
Comment 16•9 years ago
|
||
Could one of you please take this?
blocking-b2g: spark? → spark+
Flags: needinfo?(jjong)
Flags: needinfo?(btseng)
Assignee | ||
Comment 17•9 years ago
|
||
I'll take this to follow up. We can have a short-term solution to set MTU to 1280 for IPv6 and adopt the MTU from either apn settings or the one reported from modem for long-term solution.
Assignee: nobody → btseng
Flags: needinfo?(btseng)
Assignee | ||
Updated•9 years ago
|
Flags: needinfo?(jjong)
Comment 18•9 years ago
|
||
Just to let you know, we are considering disabling ipv6 on Aries/Shinano, please see bug 1171185 comment 21, so this issue will no longer exist if we use ipv4 only.
Comment 19•9 years ago
|
||
This bug is fixed by the fix for bug 1171185. The fix has just landed, we can verify this on next nightly that contains the fix.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(ktucker)
Resolution: --- → FIXED
Comment 20•9 years ago
|
||
Please verify this on the next nightly.
Comment 21•9 years ago
|
||
I just tried this on my Aries device/TMobile SIM and it is still not working for me. Gaia-Rev 1bf2da102560481748ff3f6202fbed5c4daa5832 Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/c223b8844264 Build-ID 20150614032352 Version 41.0a1 Device-Name aries FW-Release 4.4.2 FW-Incremental eng.worker.20150528.204812 FW-Date Thu May 28 20:48:20 UTC 2015 Bootloader s1
Comment 22•9 years ago
|
||
(In reply to Marcia Knous [:marcia - use ni] from comment #21) > I just tried this on my Aries device/TMobile SIM and it is still not working > for me. > > Gaia-Rev 1bf2da102560481748ff3f6202fbed5c4daa5832 > Gecko-Rev https://hg.mozilla.org/mozilla-central/rev/c223b8844264 > Build-ID 20150614032352 > Version 41.0a1 > Device-Name aries > FW-Release 4.4.2 > FW-Incremental eng.worker.20150528.204812 > FW-Date Thu May 28 20:48:20 UTC 2015 > Bootloader s1 I confirmed with nhirata that I need to do a full flash instead of shallow, so will have to try again once I do that.
Comment 23•9 years ago
|
||
Issue has been VERIFIED FIXED on aries devices. Results: Aries device with T-mobile sim is able to send MMS messages to another device. Environmental Variables: Device: Aries 3.0 Build ID: 20150614233012 Gaia: 1bf2da102560481748ff3f6202fbed5c4daa5832 Gecko: 3c26bef95d54 Gonk: 75c7e6ca80d0c7a53f346ecfcde2343be95808c9 Version: 41.0a1 (3.0) Firmware Version: D5803_23.1.A.1.28_NCB.ftf User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
Status: RESOLVED → VERIFIED
Comment 24•9 years ago
|
||
Confirming what marcia is stating in comment 22, the verify performed above was conducted on a full flash of the latest Aries build available to us by dogfood-debug.
Comment 25•9 years ago
|
||
Just tested after a full flash, confirming I can send an MMS successfully.
Updated•9 years ago
|
blocking-b2g: spark+ → 2.5+
Updated•9 years ago
|
status-b2g-v2.5:
--- → fixed
Target Milestone: --- → 2.2 S14 (12june)
Updated•9 years ago
|
status-b2g-v2.5:
fixed → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•