1032064 - Bug: MMS won't send/retrieve with WiFi active

Status: RESOLVED DUPLICATE of bug 1115486

(Firefox OS Graveyard :: RIL, defect)

Description

[Mozilla_BEC]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:24.0) Gecko/20140610 Firefox/24.0 PaleMoon/24.6.2 (Nightly/Aurora)
Build ID: 20140610142618

Steps to reproduce:

ZTE Open (US_EBAY) running FirefoxOS v2.1 (I have reproduced on v2.0, v1.4, v1.3, v1.2, v1.1, and v1.0)

Have a working profile, have proper/tested APN settings for Data and MMS
Have a working WiFi profile
Have Data+WiFi enabled in Notifications Panel

Have someone send MMS with attachment (or try to send MMS)


Actual results:

When both WiFi and Data are enabled, the SMS app will attempt to use the WiFi connection to send/retrieve the MMS data. This results in a quiet failure to do so.

If the user turns off WiFi and then toggles Airplane mode on & off, the SMS app will cancel the pending send/retrieve and allow them to download/send again. This will result in an immediate connection & send/retrieve of the MMS data.


Expected results:

The SMS app should be smart enough to send/retrieve MMS attachments and data through the Data connection only, regardless of whether or not WiFi is active/enabled.

If the user explicitly has Data connection enabled, SMS app should warn the user that they will not be able to send/retrieve that particular attachment/message.

Comment 1

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

This looks related to bug 992772.

Comment 2

[Mozilla_BEC]

Thanks for helping me file it correctly Bevis.

Comment 3

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

Hi Brett,

Is it possible to have adb logcat & tcpdump in build v2.1 for us the double confirm the root cause?
You can get these logs with the instruction of the link below:
https://github.com/bevis-tseng/Debug_Tools

In addition, may I know what carrier are you subscribe to?

Thanks.

Comment 4

[Mozilla_BEC]

Bevis, yes, absolutely I will follow the instructions and get you the logs. Currently it is 4am and I'm going to sleep, however. Can it wait till tomorrow?

My carrier is cricKet Wireless (Formerly AIO Wireless), though RIL on every version of FFXOS > 1.1 defines it as AT&T (which is a bug).

Comment 5

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

(In reply to Brett Edmond Carlock from comment #4)
> Bevis, yes, absolutely I will follow the instructions and get you the logs.
> Currently it is 4am and I'm going to sleep, however. Can it wait till
> tomorrow?
Sure! We are not in a hurry.
> 
> My carrier is cricKet Wireless (Formerly AIO Wireless), though RIL on every
> version of FFXOS > 1.1 defines it as AT&T (which is a bug).
Thanks for your information.

Comment 6

[Mozilla_BEC]

Bevis, as of FFXOS v2.1 2014-07-01 16:34:47, RIL is recognizing my service (correctly) as cricket.

How do I use your script files? Do I just download them and put them in my /home/username/B2G directory?

Comment 7

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

(In reply to Brett Edmond Carlock from comment #6)
> Bevis, as of FFXOS v2.1 2014-07-01 16:34:47, RIL is recognizing my service
> (correctly) as cricket.
> 
> How do I use your script files? Do I just download them and put them in my
> /home/username/B2G directory?

Yes, you can just download them into your home directory to run.
Please also make sure you have 'adb' in your PC needed for collecting the logs.
Please open 2 consoles: one for adb logcat and the other for capturing the tcpdump before starting the test.

Regards,
Bevis Tseng

Comment 8

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

BTW, you are supposed to see logs tagged with "MmsService" if the logs are correctly captured.

Comment 9

[Mozilla_BEC]

Bevis,

On FFXOS v2.1 2014-07-01 19:04:50 the MMS+WiFi appears to work inbound and outbound.

I guess the issue must have been resolved sometime between my v2.1 2014-06-29 20:41:05 build and today's v2.1 2014-07-01 19:04:50 build.

Can we mark this as resolved for now, with the option to re-open if I notice the behavior again?

Comment 10

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

(In reply to Brett Edmond Carlock from comment #9)
> Can we mark this as resolved for now, with the option to re-open if I notice
> the behavior again?

Sure, thanks for your feedback! :)

Comment 11

[Mozilla_BEC]

Bevis, this bug has returned with a vengeance on my Flame running v2.2 nightly.

Comment 12

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

Hi,

May I have your help again to collect the adb logcat & tcpdump for further analysis?
You can get these logs with the instruction of the link below:
https://github.com/bevis-tseng/Debug_Tools

Thanks!

Comment 13

[Mozilla_BEC]

Attachment: logcat.txt

Logcat of MMS failing to send because WiFi is active.

STR: Set device so both WiFi and Data Radio are on.
Reboot device
Attempt to send MMS.
Send will fail.
Disable WiFi.
Retry send.
Send succeeds.
Re-enable WiFi.
Send should still work.

Comment 14

[Mozilla_BEC]

Attachment: capture.pcap

TCPdump of MMS failing to send because WiFi is active.

STR: Set device so both WiFi and Data Radio are on.
Reboot device
Attempt to send MMS.
Send will fail.
Disable WiFi.
Retry send.
Send succeeds.
Re-enable WiFi.
Send should still work.

Comment 15

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

Hi Brett,

Thanks for your feedback. 
After checking the logcat/tcpdump and the APN settings of the carrier,
The root cause of this bug is the same to bug 992772 and bug 1053650.
1. In current Gecko design, there is no way to select the network interface for DNS query yet.
2. The MMS Proxy of this carrier is set to a hostname as 'proxy.aiowireless.net' which has to be resolved before starting the transaction.

The workaround right now is to modify the proxy hostname to it's ip address(192.168.197.78 or 192.168.197.79 according to the successful transaction in the log) in the MMS APN settings.

Hope this information is helpful to you. :)

Comment 16

[Mozilla_BEC]

Bevis,

Any time :)

1) Okay. Is this something that will get fixed? I doubt CricKet is the only proxy by name, as my AT&T phones also used proxy by name.

2) Which one do I use!? Is there a way to test which is the "best"?

Thanks for all your help!

Comment 17

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

(In reply to Brett Edmond Carlock from comment #16)
> Bevis,
> 
> Any time :)
> 
> 1) Okay. Is this something that will get fixed? I doubt CricKet is the only
> proxy by name, as my AT&T phones also used proxy by name.
Yes, bug 992772 and bug 1053650 are ongoing to improve this.
> 2) Which one do I use!? Is there a way to test which is the "best"?
Just pick the first one. There shall not be too much difference.

Comment 18

[Mozilla_BEC]

Thank you so much. Honestly, thanks a ton for helping me :)

Comment 20

[Daniel Holbert [:dholbert]]

I don't think this is 2.2-specific, is it?  (Comment 0 indicates that this was reproducible on v2.1, v2.0, v1.4, v1.3, v1.2, v1.1, and v1.0. Personally, I've hit this on 2.1.)

Dropping [2.2] from summary, to avoid giving the impression that this is a regresion in 2.2. (or otherwise 2.2-specific)

Comment 21

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

(In reply to Daniel Holbert [:dholbert] from comment #20)
> I don't think this is 2.2-specific, is it?  (Comment 0 indicates that this
> was reproducible on v2.1, v2.0, v1.4, v1.3, v1.2, v1.1, and v1.0.
> Personally, I've hit this on 2.1.)
> 
> Dropping [2.2] from summary, to avoid giving the impression that this is a
> regresion in 2.2. (or otherwise 2.2-specific)

Yes! Thanks for updating this.

Comment 22

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

(In reply to Brett Edmond Carlock from comment #18)
> Thank you so much. Honestly, thanks a ton for helping me :)
You're welcome! :)