Ralph Daub [:rdaub] Reporter
	Description • 10 years ago

When Wi-Fi is connected, I seem to not be able to receive/send MMS.

When Wi-Fi is connected, the icon for "Edge/3G/H" data connection is not displayed. 

When I disconnect from Wi-Fi, then disconnect/reconnect data connection, the icon for "Edge/3G/H" data connection appears. This seems to be the only way to send/receive MMS.

ENVIRONMENT:
Flame Device
Base Build v123
Shallow Flash: Gecko/Gaia v2.0
Build ID: 20140721000201

STEPS TO REPRODUCE:
1. Turn on Wi-Fi. 
2. Make sure that the status bar shows Wi-Fi connection, and that no "Edge/3G/H" data connection appears on the status bar.
3. Send a picture MMS to someone, or have someone send a picture MMS to your phone.

EXPECTED RESULTS:
The picture MMS should be sent/received successfully. If there is an error or if the connection is stagnant, the transmission should time-out so that the user may attempt to send again.

ACTUAL RESULTS:
The picture MMS is not sent/received when Wi-Fi is connected. The spinning circle keeps spinning for many minutes (29 minutes on my latest test sending MMS) before it shows the failed exclamation point.

If I disable Wi-Fi and enable data connection, thus showing the "Edge/3G/H" icon on the status bar, the circle keeps spinning. I have to restart the phone and attempt sending/receiving the MMS with a data connection active.


Please let me know if there is any information I could provide to help with the investigation and troubleshooting of this issue.

Thanks!!
- Ralph

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 1 • 10 years ago

Hi,

Would you please help to get both logcat and tcpdump for further analysis?
https://github.com/bevis-tseng/Debug_Tools

Thanks!

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 2 • 10 years ago

Can we confirm if this issue happens on devices other than Flame first? Thank you.

	Ralph Daub [:rdaub] Reporter
	Comment 3 • 10 years ago

Hi Hsin-Yi,

I've been able to reproduce this issue on other devices in the past, but I can't remember which specific ones. 

I tested it on the ZTE Open C v1.3 (Ebay) over the weekend and reproduced this issue.

I am currently recording the logcat and TCPdump per Bevis Tseng's instructions.

Thanks,

- Ralph

	Ralph Daub [:rdaub] Reporter
	Comment 5 • 10 years ago

Steps performed in "sendMMS_wifi_Disabled" logs:
1. Disable wifi.
2. Open SMS app.
3. Tap on an existing thread.
4. Add attachment (1 MB compressed to 100kb).
5. Send.

The MMS was sent in just a few seconds.

	Ralph Daub [:rdaub] Reporter
	Comment 7 • 10 years ago

Steps performed in "sendMMS_wifi_Enabled" logs:
1. Connect to wifi.
2. Open SMS app.
3. Tap on an existing thread.
4. Add attachment (1 MB compressed to 100kb).
5. Send.

The spinning circle remained for about 15 minutes before receiving an error message that the MMS could not be sent.

	Ralph Daub [:rdaub] Reporter
	Comment 8 • 10 years ago

Additionally - in one of my tests (logcat not available), this issue did NOT reproduce. The MMS was delivered successfully one time when wifi was ENABLED, but it took roughly 10 minutes.

I hope this information helps. 

Thanks!! =)

- Ralph

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 9 • 10 years ago

Thanks for capturing both positive & negative logs.
It's truly helpful to dig out the problem. :-)

After further analysis, the root cause is related to the limitation of current DNSService implementation of being not able to specify the network interface for the host to be resolved. 
(See Bug 992772).

The reasons are that:
1. There is no mms proxy in the APN of this carrier and the mmsc is mms.msg.eng.t-mobile.com.
2. This host can be resolved in both internet and private network but the ip address is different.
   ("66.94.0.185" in public network and "10.184.75.129" in private network)
3. In WiFi On case, the DNS will always be the public one.
4. After connection & host is resolved, device sent the MMS to "66.94.0.185" in private network.(K.O.)

Currently, the workaround for this issue is to replace "mms.msg.eng.t-mobile.com" to "10.184.75.129" in your MMS APN settings to skip the incorrect host resolving.

A formal solution will be available after bug 992772 is fixed.

	Ralph Daub [:rdaub] Reporter
	Comment 11 • 9 years ago

For tracking purposes -
Another user is reporting this issue in the SUMO forums: https://support.mozilla.org/en-US/questions/1037630

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 12 • 9 years ago

(In reply to Ralph Daub [:rdaub] from comment #11)
> For tracking purposes -
> Another user is reporting this issue in the SUMO forums:
> https://support.mozilla.org/en-US/questions/1037630

Hi,

I just visited the Simple Mobile Website for the apn settings.
I found that there are multiple options for mms apn settings one of which provides mms proxy(ip-based) to be configured. This could prevent flame to do DNS query when proxy is available and is ip-based.

With similar workaround to comment 9, we could suggest the user to add the mms proxy & mms port of it message settings of APN as followed, and give it a trial:
mms proxy: 216.155.165.50
mms port: 8080

	Ralph Daub [:rdaub] Reporter
	Comment 13 • 9 years ago

Thanks for the suggestion Bevis! I informed the user of this possible solution.

- Ralph

	Ralph Daub [:rdaub] Reporter
	Comment 14 • 9 years ago

Hi Bevis,

I can still reproduce this issue on the Flame running the latest v2.2 image, on top of the v18D base image. 

   Device: Flame
   Base image: v18D for Mozilla employees / contractors
   Operating System: b2g 2.2 daily user build for Tue Jan 27, 2015

I'm reopening this bug to investigate.

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 15 • 9 years ago

(In reply to Ralph Daub [:rdaub] from comment #14)
> Hi Bevis,
> 
> I can still reproduce this issue on the Flame running the latest v2.2 image,
> on top of the v18D base image. 
> 
>    Device: Flame
>    Base image: v18D for Mozilla employees / contractors
>    Operating System: b2g 2.2 daily user build for Tue Jan 27, 2015
> 
> I'm reopening this bug to investigate.

Hi Ralph,

I believe this bug still exists because bug 1115486 is still under development.

	Moreia
	Comment 16 • 9 years ago

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #12)
> (In reply to Ralph Daub [:rdaub] from comment #11)
> > For tracking purposes -
> > Another user is reporting this issue in the SUMO forums:
> > https://support.mozilla.org/en-US/questions/1037630
> 
> Hi,
> 
> I just visited the Simple Mobile Website for the apn settings.
> I found that there are multiple options for mms apn settings one of which
> provides mms proxy(ip-based) to be configured. This could prevent flame to
> do DNS query when proxy is available and is ip-based.
> 
> With similar workaround to comment 9, we could suggest the user to add the
> mms proxy & mms port of it message settings of APN as followed, and give it
> a trial:
> mms proxy: 216.155.165.50
> mms port: 8080

I am the user who posted the issue at https://support.mozilla.org/en-US/questions/1037630 

I tried updating the MMS Proxy and Port and my outgoing MMS message spun for 25 minutes and timed out ("The message could not be sent. Try again?")

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 17 • 9 years ago

(In reply to Moreia from comment #16)
> (In reply to Bevis Tseng[:bevistseng][:btseng] from comment #12)
> > (In reply to Ralph Daub [:rdaub] from comment #11)
> > > For tracking purposes -
> > > Another user is reporting this issue in the SUMO forums:
> > > https://support.mozilla.org/en-US/questions/1037630
> > 
> > Hi,
> > 
> > I just visited the Simple Mobile Website for the apn settings.
> > I found that there are multiple options for mms apn settings one of which
> > provides mms proxy(ip-based) to be configured. This could prevent flame to
> > do DNS query when proxy is available and is ip-based.
> > 
> > With similar workaround to comment 9, we could suggest the user to add the
> > mms proxy & mms port of it message settings of APN as followed, and give it
> > a trial:
> > mms proxy: 216.155.165.50
> > mms port: 8080
> 
> I am the user who posted the issue at
> https://support.mozilla.org/en-US/questions/1037630 
> 
> I tried updating the MMS Proxy and Port and my outgoing MMS message spun for
> 25 minutes and timed out ("The message could not be sent. Try again?")

Hi,

I am not pretty sure if you are able to capture the adb logcat from the device.
If yes, would you please follow the instruction below:
https://github.com/bevis-tseng/Debug_Tools
to
1. run the enable_debug_flags.sh to enable the related debug flags in the device.
2. follow instruction in step 4) to capture the main logcat.

If no, would you mind to capture the screenshot of the MMS APN settings of your device for reference.

This information could be helpful for us to know what happened on your device. :)

Thanks!

	Julien Wajsberg [:julienw]
	Comment 18 • 9 years ago

Hey Bevis, do you believe this is fixed now ?

	Moreia
	Comment 19 • 9 years ago

Still not working for me, and I'm on 2.2 now.

I will make some time this weekend to get debugging set up and capture the adb logcat.

	Julien Wajsberg [:julienw]
	Comment 20 • 9 years ago

Thanks, this would be really useful !

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 21 • 9 years ago

(In reply to Moreia from comment #19)
> Still not working for me, and I'm on 2.2 now.
> 
> I will make some time this weekend to get debugging set up and capture the
> adb logcat.

Hi,

Due to the dependency to AOSP version to KK, would you please ensure that you are running Flame-KK 2.2 or master to see if the symptom is fixed.
If no, please kindly have the adb logcat & tcpdump captured by the instructions in comment 17.

Thanks!

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 22 • 9 years ago

Since the dependency(bug 1115486) was fixed, 
I'd like to set qawanted to double confirm that this bug is fixed in flame-kk 2.2 & m-c.

	Bevis Tseng[:bevis][:btseng](Exited)
	Comment 23 • 9 years ago

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #22)
> Since the dependency(bug 1115486) was fixed, 
> I'd like to set qawanted to double confirm that this bug is fixed in
> flame-kk 2.2 & m-c.

If it is still reproducible, please help to capture the adb logcat & tcpdump in m-c for further analysis.

Thanks!

	Julien Wajsberg [:julienw]
	Comment 24 • 9 years ago

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #21)
> (In reply to Moreia from comment #19)
> > Still not working for me, and I'm on 2.2 now.
> > 
> > I will make some time this weekend to get debugging set up and capture the
> > adb logcat.
> 
> Hi,
> 
> Due to the dependency to AOSP version to KK, would you please ensure that
> you are running Flame-KK 2.2 or master to see if the symptom is fixed.
> If no, please kindly have the adb logcat & tcpdump captured by the
> instructions in comment 17.

Oh ok, now I know why I still saw this issue on my 2.2 Open C: it's Jelly Bean based.

I don't know if we should try to fix this on JB as well, likely not as I think Open C is the only phone that gets updates with the community builds.

	Pi Wei Cheng [:piwei] (inactive)
	Comment 25 • 9 years ago

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #22)
> Since the dependency(bug 1115486) was fixed, 
> I'd like to set qawanted to double confirm that this bug is fixed in
> flame-kk 2.2 & m-c.

I was able to send/receive MMS's with only Wifi connection on Flame 3.0 and 2.2.

Device: Flame (KK, full flashed, 319MB)
BuildID: 20150619002501
Gaia: 1c33072e33c279c8aa5cb5e4a3e4da6af6cd818b
Gecko: 5ad34a170633
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Device: Flame (KK, full flashed, 319MB)
BuildID: 20150619010205
Gaia: a0df9c367a68764bdcf2e2e1c4d27f0d6ee165b8
Gecko: 2694ff2ace6a
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

	BMO Automation
	Comment 26 • 6 years ago

Firefox OS is not being worked on