If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED DUPLICATE of bug 1032064

Status

Firefox OS
RIL
RESOLVED DUPLICATE of bug 1032064
3 years ago
3 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

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

Comment 1

3 years ago
Created attachment 8493518 [details]
screenshot of MMS (with "download" link)
(Reporter)

Comment 2

3 years ago
Created attachment 8493519 [details]
screenshot of MMS, after clicking "download" (indefinitely downloading)
(Reporter)

Comment 3

3 years ago
OS Version: 2.1.0.0-prerelease
Build Identifier: 20140921160204
Update Channel: aurora
Git commit info: 2014-09-20 01:30:31  b3f9b97d
(Reporter)

Comment 4

3 years ago
device: Flame
(Reporter)

Updated

3 years ago
Summary: Multi-recipient MMS (sent from an iPhone) has "Download" link, but never finishes downloading (so, can never be read) → Multi-recipient MMS (sent from iPhone to Flame) has "Download" link, but never finishes downloading (so, can never be read)
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 hidden (obsolete)
Comment hidden (obsolete)
(Reporter)

Comment 8

3 years ago
Sent logcat & pcap file via email.
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
(Reporter)

Comment 10

3 years ago
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.)
Summary: Multi-recipient MMS (sent from iPhone to Flame) has "Download" link, but never finishes downloading (so, can never be read) → Multi-recipient MMS (received on Flame on T-Mobile's network) has "Download" link, but never finishes downloading (so, can never be read)
(Reporter)

Comment 11

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

Comment 12

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

Comment 13

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

Updated

3 years ago
Summary: Multi-recipient MMS (received on Flame on T-Mobile's network) has "Download" link, but never finishes downloading (so, can never be read) → 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
(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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1053650
(Reporter)

Comment 15

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

Updated

3 years ago
See Also: → bug 1071441
Component: Gaia::SMS → RIL
(Reporter)

Comment 17

3 years ago
This is more accurately a dupe of bug 1032064, I think (which depends on bug 1053650). Marking as such.
Duplicate of bug: 1032064
You need to log in before you can comment on or make changes to this bug.