1071401 - Multi-recipient MMS (received on Flame on T-Mobile's network) has "Download" link, but never finishes downloading (so, can never be read), when connected over WiFi

Status: RESOLVED DUPLICATE of bug 1032064

(Firefox OS Graveyard :: RIL, defect)

Description

[Daniel Holbert [:dholbert]]

I just received a MMS from a friend, but I'm unable to view it.

The Gaia SMS app just says:
> Attachment can be downloaded until Thursday, Sep 25.
> [link]Download[/link]
> 7:56 PM (!)

The "(!)" is a little red exclamation-in-a-circle "warning" indicator of some sort, but I have no idea what its significance is.

If I click the Download link, it says "Downloading..." and never changes (never finishes downloading). If I reboot my phone, it goes back to the initial state with the "Download" link.

MORE DETAILS:
 - I'm running Firefox OS 2.1, on the "aurora" nightly channel.
 - I believe the MMS was sent from an iPhone on the new iOS (version 8).
 - The text didn't have any media content -- it was only an MMS because it had multiple recipients, I believe.  It was like a paragraph of text. (I know this because my girlfriend received a copy of the MMS on her Android phone.)

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: screenshot of MMS (with "download" link)

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screenshot of MMS, after clicking "download" (indefinitely downloading)

Comment 3

[Daniel Holbert [:dholbert]]

OS Version: 2.1.0.0-prerelease
Build Identifier: 20140921160204
Update Channel: aurora
Git commit info: 2014-09-20 01:30:31  b3f9b97d

Comment 4

[Daniel Holbert [:dholbert]]

device: Flame

Comment 5

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi,

Would you please help to collect the adb logcat & and tcpdump for further analysis?
(https://github.com/bevis-tseng/Debug_Tools)

I'd like to check what was received by the device and why it failed after you trigger
the "download" manually.

Thanks!

Comment 6

[Daniel Holbert [:dholbert]]

Nothing shows up in logcat when I open Messages or when I tap "Download", but this series of 3 messages show up every 5 seconds & look like they could conceivably be connected (though they're there before I even open the Messages app, after a reboot, so they're maybe not connected after all):
{
09-22 21:31:35.634 E/QCALOG  (  425): [MessageQ] ProcessNewMessage: [XTWiFi-PE] unknown deliver target [OS-Agent]
09-22 21:31:35.634 E/QCALOG  (  425): [MessageQ] ProcessNewMessage: [XTWWAN-PE] unknown deliver target [OS-Agent]
09-22 21:31:35.644 E/QCALOG  (  425): [MessageQ] ProcessNewMessage: [XT-CS] unknown deliver target [OS-Agent]
}
They seem to be paired with some other messages from repeating entries for wpa_supplicant (and are displaying before I open Messages), so I'm guessing this isn't really related to the MMS.

I'll take a look at the tcpdump tool.

Comment 7

[Daniel Holbert [:dholbert]]

(Sorry, comment 6 was before I'd run "enable_debug_flags.sh". With that script, I do seem to get some interesting output from logcat.)

Comment 8

[Daniel Holbert [:dholbert]]

Sent logcat & pcap file via email.

Comment 9

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Daniel,

Thanks for your information.
From the logs, it seems more likely to be a problem in T-Mobile's MMSC because I saw the following error return from the server:
09-22 21:48:30.977   290   588 E GeckoConsole: [JavaScript Error: "atl2mosget.msg.eng.t-mobile.com : server does not support RFC 5746, see CVE-2009-3555"]
09-22 21:48:31.097   290   290 I Gecko   : -@- MmsService: xhr done, but status = 501, statusText = Not Implemented

Comment 10

[Daniel Holbert [:dholbert]]

The first message there about the CVE is unrelated & can be ignored -- I see it all the time in my browser console, and it just is a hint to server operators that they might be vulnerable to something. See http://stackoverflow.com/questions/3575233/how-to-by-pass-following-error-in-firefox-extension-server-does-not-support-rfc and https://support.mozilla.org/en-US/questions/746438 for more on that.

I don't know what the second message means, though.  Does that indicate that something's missing on T-Mobile's end? (I'm not clear on whether "not implemented" is coming from us or from them.)

Comment 11

[Daniel Holbert [:dholbert]]

(It seems like we're reacting to the 501 Not Implemented by backing off & retrying after an increasing timeout (starting at a minute), and just displaying "Downloading..." indefinitely in the UI.

I wonder if we should really be displaying an error message of some sort [and restoring the Download link, so that users can click it if & when they want]...)

Comment 12

[Daniel Holbert [:dholbert]]

Nice, "Download" works (gets me the MMS) after a second or two if I disable WiFi!

So it seems that we're sending MMS queries over the WiFi connection (if enabled), whereas T-Mobile only responds to requests for MMS's sent over their own data network. Or something like that.

Comment 13

[Daniel Holbert [:dholbert]]

In the failed-with-WiFi log, I have:
{
Gecko   : -*- NetworkManager: hostname is resolved: atl2mosget.msg.eng.t-mobile.com
Gecko   : -*- NetworkManager: Addresses: ["66.94.0.188"]
Gecko   : -*- NetworkService: addHostRoute 66.94.0.188 on rmnet0
[...]
Gecko   : -@- MmsService: xhr done, but status = 501, statusText = Not Implemented
Gecko   : -@- MmsService: Fail to retrieve. Will retry after: 60000
}
vs. in the succeeded-with-WiFi-off log, I have:
{
Gecko   : -*- NetworkManager: hostname is resolved: atl2mosget.msg.eng.t-mobile.com
Gecko   : -*- NetworkManager: Addresses: ["10.184.75.130"]
Gecko   : -*- NetworkService: addHostRoute 10.184.75.130 on rmnet0
[...]
Gecko   : -@- MmsService: xhr success, response headers: Content-Type: application/vnd.wap.mms-message
Gecko   : Content-Length: 488
}

So when I'm connected over my cell data connection, I get an internal (10.*) IP address, and the XHR succeeds.

Comment 14

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Daniel Holbert [:dholbert] from comment #13)
> In the failed-with-WiFi log, I have:
> {
> Gecko   : -*- NetworkManager: hostname is resolved:
> atl2mosget.msg.eng.t-mobile.com
> Gecko   : -*- NetworkManager: Addresses: ["66.94.0.188"]
> Gecko   : -*- NetworkService: addHostRoute 66.94.0.188 on rmnet0
> [...]
> Gecko   : -@- MmsService: xhr done, but status = 501, statusText = Not
> Implemented
> Gecko   : -@- MmsService: Fail to retrieve. Will retry after: 60000
> }
> vs. in the succeeded-with-WiFi-off log, I have:
> {
> Gecko   : -*- NetworkManager: hostname is resolved:
> atl2mosget.msg.eng.t-mobile.com
> Gecko   : -*- NetworkManager: Addresses: ["10.184.75.130"]
> Gecko   : -*- NetworkService: addHostRoute 10.184.75.130 on rmnet0
> [...]
> Gecko   : -@- MmsService: xhr success, response headers: Content-Type:
> application/vnd.wap.mms-message
> Gecko   : Content-Length: 488
> }
> 
> So when I'm connected over my cell data connection, I get an internal (10.*)
> IP address, and the XHR succeeds.

Hi Daniel,

Thanks for your clarification.
Yes, this is a known issue which has been addressed in bug 1053650.
In current design, we are not able to support DNS query with specified interface yet.

Comment 15

[Daniel Holbert [:dholbert]]

Sounds like this may be a known issue with T-Mobile (& not Firefox OS dependent), too, FWIW.

Googling for "t-mobile mms wifi" turns up support pages like these:
{
 No MMS with WiFi enabled? | T-Mobile Support
 http://support.t-mobile.com/thread/56934

 Nexus 5 - No MMS on Wifi | T-Mobile Support
 http://support.t-mobile.com/message/332228
}

...and one of their support people says this is known-to-not-work (unless you enable "WiFi calling"):
  http://support.t-mobile.com/message/333602#333602
(I'm guessing "wifi calling" involves a VPN or equivalent that connects your phone to their 10.* network, or involves another way of getting your MMS's. It requires custom software from them, I think, so it's not an option for us.)

Doing an interface-specific DNS query does sound like it would address this.

In the meantime, I might spin off a followup on improving the UI, since the current UI ("downloading..." forever) is misleading. It gives the user false hope that something is actually downloading, when really nothing is downloading.  (See also comment 11)

Comment 16

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to Daniel Holbert [:dholbert] from comment #15)
> Sounds like this may be a known issue with T-Mobile (& not Firefox OS
> dependent), too, FWIW.
> 
> Googling for "t-mobile mms wifi" turns up support pages like these:
> {
>  No MMS with WiFi enabled? | T-Mobile Support
>  http://support.t-mobile.com/thread/56934
> 
>  Nexus 5 - No MMS on Wifi | T-Mobile Support
>  http://support.t-mobile.com/message/332228
> }
> 
> ...and one of their support people says this is known-to-not-work (unless
> you enable "WiFi calling"):
>   http://support.t-mobile.com/message/333602#333602
> (I'm guessing "wifi calling" involves a VPN or equivalent that connects your
> phone to their 10.* network, or involves another way of getting your MMS's.
> It requires custom software from them, I think, so it's not an option for
> us.)
> 
Thanks for your information. 
By my understanding, it's not related to the WiFi calling.
WiFi Calling is T-Mobile VoIP service over public WiFi with IMS authentication of the inserted SIM.
It's normal that MMS is not able to transmit over WiFi.
MMS service shall be transacted over mobile network because there is no authentication available in MMS Service. :)

> Doing an interface-specific DNS query does sound like it would address this.
> 
> In the meantime, I might spin off a followup on improving the UI, since the
> current UI ("downloading..." forever) is misleading. It gives the user false
> hope that something is actually downloading, when really nothing is
> downloading.  (See also comment 11)

Comment 17

[Daniel Holbert [:dholbert]]

This is more accurately a dupe of bug 1032064, I think (which depends on bug 1053650). Marking as such.