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)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.5+, b2g-master fixed)

VERIFIED FIXED
2.2 S14 (12june)
blocking-b2g 2.5+
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
Link to failed test case: https://moztrap.mozilla.org/manage/case/10742/
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
[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)
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)
(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)
Attached file tcpdump
Attached file logcat_main.txt
Attached file logcat_radio.txt
(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.
Attached file capture.pcap
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)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qaurgent, qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
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.
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...
(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
(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
Could one of you please take this?
blocking-b2g: spark? → spark+
Flags: needinfo?(jjong)
Flags: needinfo?(btseng)
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)
Flags: needinfo?(jjong)
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.
See Also: → 1171185
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
Please verify this on the next nightly.
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Keywords: qawanted, verifyme
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
(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.
    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
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.
Just tested after a full flash, confirming I can send an MMS successfully.
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted, verifyme
blocking-b2g: spark+ → 2.5+
Target Milestone: --- → 2.2 S14 (12june)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: