1003247 - [B2G][SMS][Messaging] Not able to send MMS under AT&T network when WiFi and Data Connection are set to OFF.

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: Logcat, Firewatch

Description:
When sending an MMS through the gallery app, the sending time will take much longer than expected. When sending an MMS by attaching a picture it does seem to take less time

Repro Steps:
1) Update a Tarako to BuildID: 20140428014001
2) Open gallery> Select a picture> tap on share icon
3) Tap on Messages
4) Select a contact, or type in a phone number and send the message

Actual:
The MMS message will take a very long time to send (5-30 mins)

Expected:
The MMS message will process and take a short time to send

1.3t Environmental Variables:
Device: Tarako 1.3t
BuildID: 20140428014001
Gaia: 8895b180ed636069473703d0e7b73086989601ce
Gecko: 7caf4b5abfce
Version: 28.1
Firmware Version: sp6821

Keywords: SMS, Gallery, Photo, Picture, Receive, Tarako

Notes: Similar to bug 976897

Repro frequency: 100%
See attached: Logcat, Firewatch, Screenshot

Comment 1

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: 2014-04-29-09-12-02.png

Comment 2

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

The issue above does not occur on Buri 1.3


1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140425024003
Gaia: 32a9e3db738e0b3bc44a4d4d5c16512a2617a2cf
Gecko: c96b0cf6343f
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 3

[Julien Wajsberg [:julienw]]

(In reply to dharris from comment #0)
> Created attachment 8414573 [details]
> Logcat, Firewatch
> 
> Description:
> When sending an MMS through the gallery app, the sending time will take much
> longer than expected. When sending an MMS by attaching a picture it does
> seem to take less time

There is no difference between these cases.

> 
> Repro Steps:
> 1) Update a Tarako to BuildID: 20140428014001
> 2) Open gallery> Select a picture> tap on share icon
> 3) Tap on Messages
> 4) Select a contact, or type in a phone number and send the message
> 
> Actual:
> The MMS message will take a very long time to send (5-30 mins)
> 
> Expected:
> The MMS message will process and take a short time to send
> 
> 1.3t Environmental Variables:
> Device: Tarako 1.3t
> BuildID: 20140428014001
> Gaia: 8895b180ed636069473703d0e7b73086989601ce
> Gecko: 7caf4b5abfce
> Version: 28.1
> Firmware Version: sp6821
> 
> Keywords: SMS, Gallery, Photo, Picture, Receive, Tarako
> 
> Notes: Similar to bug 976897
> 
> Repro frequency: 100%
> See attached: Logcat, Firewatch, Screenshot

Can we please have a logcat with RIL and MMS debugging enabled ?
The easiest is to take my "addpref" script in [1] and run it "addpref logs". This will reboot the phone.

[1] https://github.com/julienw/config-files/blob/master/addpref

Thanks !

Comment 4

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: Logcat_MMS.txt

Logcat with RIL and MMS debugging enabled attached

Comment 5

[Julien Wajsberg [:julienw]]

Bevis will make sense out of this :)

Comment 6

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

Thanks Julien & reporter for collecting the logs.
I'll look into it and feedback you soon.

Comment 7

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

Attachment: tcpdump

Upload tcpdump executive.

Step to capture tcpdump:
  1. Install attached tcpdump command into test device:
     $adb remount; adb push tcpdump system/bin/;adb shell chmod 777 /system/bin/tcpdump
  2. Start capturing tcpdump:
     $adb shell tcpdump -i any -p -s 0 -w /data/capture.pcap
  3. backup tcpdump result:
     $adb pull /data/capture.pcap .

Comment 8

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

After checking the log, the reason that tarako takes more time to send MMS mesage is:
1. The 1st trial of sending MMS is failed with HTTP status to 0.
2. The device started next trial after 5 minutes.
3. The MMS is sent successfully in 2nd trial.
There is no difference between 1st trial and 2nd trial from MmsService perspective.

NI for 
1. In comment 0, "Repro frequency: 100%". Does that means sending MMS with Tarako always takes 5 minutes due to the failure in 1st trial?
2. Since Buri with 1.3 build is okay, we need to compare the difference from the logs to be captured from both Buri & Tarako:
   - adb logcat with RIL/MMS logs enabled as mentioned in comment 3.
   - capture tcpdump with the command uploaded in comment 7.

Thanks.

Comment 9

[Joe Cheng [:jcheng] (please needinfo)]

can this be normal on tarako?
since MMS is sent over the cellular network and Tarako is a 2G device in the end.
Can we try to lock buri to 2G and compare?
Thanks

Comment 10

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Yes Bevis, it takes 5 minutes or more to send an MMS every time. I have seen it take up to 30 minutes to send.

Comment 11

[Duane Dixon [:ddixon]]

Issue DOES reproduce on a 2G 1.3T Tarako device.  

NOTICE: Issue ONLY reproduces on a 2G Tarako and 2G Buri device IF the "E" feature on the notification menu is turned OFF.  If the "E" feature is on, the issue DOES NOT reproduce.

(Not able to pull Tarako variables at this time.)  

1.4 Environmental Variables:
Device: buri 1.4 MOZ
BuildID: 20140430115207
Gaia: e729838c39856046f5526468b18cfa507bd613a6
Gecko: 69ae2efbe943
Version: 30.0
Firmware Version: v1.2-device.cfg

Comment 12

[Jason Smith [:jsmith]]

(In reply to ddixon from comment #11)
> Issue DOES reproduce on a 2G 1.3T Tarako device.  
> 
> NOTICE: Issue ONLY reproduces on a 2G Tarako and 2G Buri device IF the "E"
> feature on the notification menu is turned OFF.  If the "E" feature is on,
> the issue DOES NOT reproduce.
> 
> (Not able to pull Tarako variables at this time.)  
> 
> 1.4 Environmental Variables:
> Device: buri 1.4 MOZ
> BuildID: 20140430115207
> Gaia: e729838c39856046f5526468b18cfa507bd613a6
> Gecko: 69ae2efbe943
> Version: 30.0
> Firmware Version: v1.2-device.cfg

Does the scenario above reproduce on a 1.3 buri device?

Comment 13

[Duane Dixon [:ddixon]]

I worked with [e-mail] and found reliable steps that reproduce this issue on a Buri device. 

Issue DOES occur on a 1.3 Buri (2G) device with the following STR:

1. Turn off "E" feature in Notifications menu. 
2. Power down device. 
3. Turn device back on. 
4. Open Camera App>take photo>send photo as an MMS>select contact>send message
5. Observe that the message takes about 15+ minutes to send or FAILS to send completely.

Repro Rate: 9/10

1.3 Environmental Variables:
Device: buri 1.3 MOZ
BuildID: 20140428024001
Gaia: 32a9e3db738e0b3bc44a4d4d5c16512a2617a2cf
Gecko: d7b1e90008e5
Version: 28.0
Firmware Version: v1.2-device.cfg

Comment 14

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

Not able to repo this locally.
NI for the following logs in both Buri/Tarako to see what happened in these 2 devices in the test network:
 - adb logcat with RIL/MMS logs enabled as mentioned in comment 3.
 - capture tcpdump with the command uploaded in comment 7.

Comment 15

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: Logcat

TCP dumps for Buri 1.3/Tarako added, as well as the Logact for Buri 1.3

Comment 16

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: TCPDumpTarako.pcap

Comment 17

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: TCPDumpBuri.pcap

Comment 18

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

I cannot see anything abnormal from the new attached logs in comment 15, 16, 17.
For the logcat in comment 15, even Buri is locked in 2G data network (EDGE), 
the MMS still can be sent normally in 15 seconds which was not the same to 
the symptom mentioned in comment 13:
"Observe that the message takes about 15+ minutes to send or FAILS to send completely."
And the "Repro Rate is 9/10".

NI again to have the log & tcpdump again on both Buri & Tarako which includes the symptoms mentioned in comment 13 for further investigation.
(Please ensure start the logcat/tcpdump before test is started.)

Thanks,
Bevis

Comment 19

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

The logcat from comment 15 is for the Buri, and you are correct. This issue does not seem to occur on the Buri, it is a Tarako specific bug. The logcat for the tarako can be found in comment 4.

Comment 20

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

(In reply to dharris from comment #19)
> The logcat from comment 15 is for the Buri, and you are correct. This issue
> does not seem to occur on the Buri, it is a Tarako specific bug. The logcat
> for the tarako can be found in comment 4.

It is really confusing now. :-(
There is no difference in the MMS implementation in Buri & Tarako. 
Besides, in comment 13, ddixon did mentioned that 
"Issue DOES occur on a 1.3 Buri (2G) device with the following STR".

I've done the analysis in comment 8 for the log attached in comment 4 for Tarako.
However, there is no corresponding tcpdump to tell us more why the first trial was failed.
(It might also be an network issue instead.)

If this only happened in Tarako, let's focus on this issue in Tarako first to 
get the following information at the same time for the scenario of
"Observe that the message takes about 15+ minutes to send or FAILS to send completely.":
1. adb logcat
2. tcpdump
(Please ensure to start the logcat/tcpdump at the same time before test is started.)

Thanks,
Bevis

Comment 21

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

I was not able to get the behaviour stated in comment 13 ("Observe that the message takes about 15+ minutes to send or FAILS to send completely.") I did see the same result from what I had posted in comment 0 "The MMS message will take a very long time to send (5-30 mins)." I ran both the Logcat, and TCP Dump at the same time, and they are now attached below.

Comment 22

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: Logcat2_Tarako.txt

Comment 23

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: TCPDump2_Tarako.pcap

Comment 24

[Duane Dixon [:ddixon]]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #20)
> (In reply to dharris from comment #19)
> > The logcat from comment 15 is for the Buri, and you are correct. This issue
> > does not seem to occur on the Buri, it is a Tarako specific bug. The logcat
> > for the tarako can be found in comment 4.
> 
> It is really confusing now. :-(
> There is no difference in the MMS implementation in Buri & Tarako. 
> Besides, in comment 13, ddixon did mentioned that 
> "Issue DOES occur on a 1.3 Buri (2G) device with the following STR".
> 
> I've done the analysis in comment 8 for the log attached in comment 4 for
> Tarako.
> However, there is no corresponding tcpdump to tell us more why the first
> trial was failed.
> (It might also be an network issue instead.)
> 
> If this only happened in Tarako, let's focus on this issue in Tarako first
> to 
> get the following information at the same time for the scenario of
> "Observe that the message takes about 15+ minutes to send or FAILS to send
> completely.":
> 1. adb logcat
> 2. tcpdump
> (Please ensure to start the logcat/tcpdump at the same time before test is
> started.)
> 
> Thanks,
> Bevis

I apologize for any confusion.  

After further testing, I have determined my test results may be invalid (Comment 13).  

I was testing the issue on the Buri with Wifi AND the E/H feature (in Notifications menu) turned OFF.
  
This seemed to not be a valid way to test a MMS issue because the device needs a way to send jpeg files or other types of data.

Since I was not giving my device a way to send data, it seems that it should fail to send an MMS, and it did fail to do so.

Comment 25

[bhavana bajaj [:bajaj]]

Since we are on parity on with Buri under the same conditions not blocking on this for 1.3T

Comment 26

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

(In reply to ddixon from comment #24)
> I was testing the issue on the Buri with Wifi AND the E/H feature (in
> Notifications menu) turned OFF.
>   
> This seemed to not be a valid way to test a MMS issue because the device
> needs a way to send jpeg files or other types of data.
> 
> Since I was not giving my device a way to send data, it seems that it should
> fail to send an MMS, and it did fail to do so.

No, actually, it should always be able to send a MMS no mater Wifi is ON or not.

So far, we still not able to figure out what's going on because we don't have the adb logcat along with tcpdump at the same time on Tarako & Buri which includes the sypmtom of "Observe that the message takes about 15+ minutes to send or FAILS to send completely."
NI again to 
1. provide the STR of both devices of this symptom.
2. capture adb logcat along with tcpdump of both devices to figure out what was happened in Tarako & Buri.

Thanks,
Bevis

Comment 27

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Ok so after further testing and 20 attempts on both devices I have found different STR on both Buri and Tarako. The testing was done using the same SD card, and SIM card for each device as well as sending the same picture. I am seeing different behaviour from what I had seen in comment 0


STR Tarako 1.3t:

1) Restart or Resest Device
2) Open Gallery> Select a Photo> Tap the 'Share' Icon> Tap Messages 
3) Type in a valid Phone number or select a contact and send the message

Result: MMS message will take ~6+ mins to send.
Note: This issue only occurs for the first MMS message sent after a Reset or Restart. After this first message is sent, all other MMS messages will send correctly after ~15-20 seconds.

Repro Rate: 100%


1.3t Environmental Variables:
Device: Tarako 1.3t
BuildID: 20140508064242
Gaia: 554fd996205fef74d88e988f3596c58dcd05df28
Gecko: 6391e1650ec1
Version: 28.1
Firmware Version: SP6821a-Gonk-4.0-4-29


STR Buri 1.3:

1) Restart or Resest Device (Do not connect to Wifi)
2) Open Gallery> Select a Photo> Tap the 'Share' Icon> Tap Messages 
3) Type in a valid Phone number or select a contact and send the message

Result: MMS message will FAIL to send
Note: If the user connects to wifi and then sends the MMS message, the MMS message will send correctly after ~15-20 seconds. If the user then disconnects from the wifi after sending a message they are always able to correctly send MMS messages after ~15-20 seconds

Repro Rate: 100%


1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140505024001
Gaia: 667539f1ed4becc45b182a5f1046221d3eeb9e7c
Gecko: bf3fe474bf50
Version: 28.0
Firmware Version: v1.2-device.cfg


The Logcat, and TCPDumps were created at the same time for each device and are attached below.

Comment 28

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: Logact_Tarako4.txt

Comment 29

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: TCPDump_Tarako4.pcap

Comment 30

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: Logcat_Buri4.txt

Comment 31

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Attachment: TCPDump_Buri4.pcap

Comment 32

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

Thanks for collecting these logs.
We'll look into it and feedback you soon.

Comment 33

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

Update finding so far according to the latest logs:
The steps to send a MMS is as followed:
1. MmsService requests RadioInterfaceLayer to establish MMS connection.
2. After connection established, NetworkManager resolves host name of mms proxy.
3. NetworkManager add host route of the resolved ip-adddress of mms proxy.
4. MmsService starts MMS transaction after being notified from NetworkManager that
   the mms connection is ready to used.

In Tarako,
1. From the logcat, 
   the 1st trial of MO MMS transaction was terminated immediately locally with 
   response of HTTP status == 0.
2. From the tcpdump,
   the hostname of mms proxy (proxy.mobile.att.net) was resolved correctly with
   ip-address equal to 172.26.39.1.
   However, there is no MMS packet captured in the tcpdump, which means
   the packet was not actually routed to the established network interface.
   That's why the MMS transaction terminated immediately.
3. When running the 2nd trial with the same call flow,
   the MMS packet was sent out correctly.
   After checking the tcpdump, the difference compared to the first trial is that
   a. There is no dns query packet captured which means the dns cache of mms proxy from
      previous mms data connection might not be clear when torn down.

Compared with analysis #2 and #3, 
does that means somehow it takes more time when addHostRoute asynchronously in step#3 if
hostname resolving is needed in prior to addHostRoute?
And then, we encouter a timing issue to sending MMS before routing is set?

Comment 34

[Julien Wajsberg [:julienw]]

(In reply to ddixon from comment #24)
> 
> After further testing, I have determined my test results may be invalid
> (Comment 13).  
> 
> I was testing the issue on the Buri with Wifi AND the E/H feature (in
> Notifications menu) turned OFF.
>   
> This seemed to not be a valid way to test a MMS issue because the device
> needs a way to send jpeg files or other types of data.
> 
> Since I was not giving my device a way to send data, it seems that it should
> fail to send an MMS, and it did fail to do so.

To add some more explanation here: we actually enable a separate data channel when we need to send a MMS; the carriers can distinguish this specific network activity (either using a different APN or using the MMSC proxy IP) so that they don't charge the user.

Obviously this can still fail of we don't have a good network coverage.

Comment 35

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

Trying to simulate the situation locally by resolving a host before sending MMS when 1st boot-up
with no Wifi and internet data connection, I found that
1. I'll got a exception from DNSService.resolve() with NS_ERROR_OFFLINE.
2. After reviewing the implementation in NetworkManager, we found that there might be a
   timing-issue at [1], due to 2 operations:
   a) gNetworkService.addHostRoute(network);
   b. this.setExtraHostRoute(network);
   where addHostRoute() in a) was done asynchronously and setExtraHostRoute() in b) try
   to resolveHostName() synchronously.

The next action is to review NetworkManager/NetworkService/NetworkUtils and 
provide a debug gecko build with more logs for QA to capture related logs again to 
prove this timing issue is the root cause.

[1] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/file/59b3ea7e75fb/dom/system/gonk/NetworkManager.js#l203

Comment 36

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

It's not related to the timing issue mentioned in comment 35.

Root cause of "NS_ERROR_OFFLINE" was found:
1. When device bootup, DNSService.setOffline(true) by invoking NetworkManager.setAndConfigureActive() in 
   NetworkManager's constructor. 
   That means the DNSService is disable because the device is in offline state.
2. When a MMS data connection is established and is connected, the device is try to setExtraHostRoute()
   before setAndConfigureActive().
   That's means we are trying to resolve hostname in setExtraHostRoute() before enabling DNSService in 
   setAndConfigureActive().

That's why we always got NS_ERROR_OFFLINE if only mms connection is established.

Comment 37

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

Attachment: Patch v1: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

1. Change the call sequence to ensure that hostname is resolved after DNS is enabled. (Address the problem mentioned in Comment 36.)
2. Add one more log for better debugging during field trial.

Comment 38

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

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #37)
> 1. Change the call sequence to ensure that hostname is resolved after DNS is
> enabled. (Address the problem mentioned in Comment 36.)
Sorry, it shall be |DNSService| instead of |DNS| is enabled.

Comment 39

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

Attachment: Patch v2: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

1. Address problems in comment 36 to ensure the DNSService is enabled in setAndConfigureActive() before trying to resolveHostName() in setExtraHostRoute().
2. Add one more log for better debugging during field trial.

Comment 40

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

Attachment: [1.3] Patch v1: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

Rebase patch for 1.3.

Comment 41

[Jason Smith [:jsmith]]

Bevis - This only impacts Moz RIL, right? Not commercial RIL?

If so, then we can live with this for 1.3, as we're not shipping anything on production devices with the Moz RIL.

Comment 42

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

Hi Jason,

This impact both Moz RIL & Commercial RIL, because the defect is found in NetworkManager
instead of RadioInterfaceLayer.

Currently, this problem only happened when the following conditions are met:
1. Test in the carrier with the mms proxy in canonical format.
   For example, in AT&T, the MMS proxy is "proxy.mobile.att.net" instead of ip-addresses.
2. There is mobile connection for internet and Wifi are OFF when sending MMS.

Comment 43

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

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #42)
> 2. There is mobile connection for internet and Wifi are OFF when sending MMS.
The mobile connection for internet and Wifi are OFF when sending MMS.

Comment 44

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 8422171 [details] [diff] [review]
Patch v2: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

Review of attachment 8422171 [details] [diff] [review]:
-----------------------------------------------------------------

Unless we can find a way to resolve via a specific interface, there seems no other better solution for this.  Thank you.

Comment 45

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #44)
> Review of attachment 8422171 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Unless we can find a way to resolve via a specific interface, there seems no
> other better solution for this.  Thank you.

BTW, could you help comment a little bit more for the reason this line has to be after setAndConfigureActive()?  So that we don't accidentally commit changes not taking this restriction into consideration in the future.  Thank you again.

Comment 46

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 8422173 [details] [diff] [review]
[1.3] Patch v1: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

Review of attachment 8422173 [details] [diff] [review]:
-----------------------------------------------------------------

Please also add some explanations in this patch.  Thank you.

Comment 47

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

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #45)
> (In reply to Vicamo Yang [:vicamo][:vyang] from comment #44)
> > Review of attachment 8422171 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > Unless we can find a way to resolve via a specific interface, there seems no
> > other better solution for this.  Thank you.
> 
> BTW, could you help comment a little bit more for the reason this line has
> to be after setAndConfigureActive()?  So that we don't accidentally commit
> changes not taking this restriction into consideration in the future.  Thank
> you again.

Will do. :)

Comment 48

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

Attachment: Patch v3: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

update comments to explain the reason of this modification.

Comment 49

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

Attachment: [1.3] Patch v2: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

update comments for 1.3 patch.

Comment 50

[Jason Smith [:jsmith]]

Vance - Can you find out if this is a cert blocker for TCL?

Comment 51

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

It is a cert blocker for TCL since for some countries they did test MMS with 2G Network. Please help to land it on 1.3 as well

Thanks

Vance

Comment 52

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

Comment on attachment 8422914 [details] [diff] [review]
[1.3] Patch v2: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 886765.
User impact if declined: Fail to get ceritifcate to pass the following scenario: 
Under carrier's with MMS Proxy as domain name instead of ip-address, device is not able to send MMS if both internet/WiFi are OFF.
Testing completed: Y
Risk to taking this patch (and alternatives if risky): NO
String or UUID changes made by this patch:N/A

Comment 53

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

Comment on attachment 8422913 [details] [diff] [review]
Patch v3: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 886765.
User impact if declined: Fail to get ceritifcate to pass the following scenario: 
Under carrier's with MMS Proxy as domain name instead of ip-address, device is not able to send MMS if both internet/WiFi are OFF.
Testing completed: Y
Risk to taking this patch (and alternatives if risky): NO
String or UUID changes made by this patch:N/A

Comment 54

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

update try server result for both 1.3/master:
(Master) https://tbpl.mozilla.org/?tree=Try&rev=daec56f25777
(1.3) https://tbpl.mozilla.org/?tree=Try&rev=e3d9f0d3b12e

Comment 55

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/2fb0ab852ec5

Comment 56

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/2fb0ab852ec5

Comment 57

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8422913 [details] [diff] [review]
Patch v3: Ensure to setExtraHostRoute() after setAndConfigureActive() is done. r=vyang

1.3 blockers don't need approval to land on 1.4

Comment 58

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/866fdb4b660a

Comment 59

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

Update bug title according to the root cause found in comment 36:
- NetworkManager tried to resolve hostname of MMS Proxy/MMSC before DNSService in gecko is enabled.

STR of this bug:
- Insert AT&T SIM.
- Turn off WiFi & Data Connection.
- Reboot the device.
- Send a MMS under AT&T network.

Comment 60

[Jason Smith [:jsmith]]

Clearing in-moztrap - this doesn't hit the criteria for an in-moztrap nomination (which is either a partner found bug or an invalid test case).

Comment 61

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #60)
> Clearing in-moztrap - this doesn't hit the criteria for an in-moztrap
> nomination (which is either a partner found bug or an invalid test case).

Talked with bbajaj about this - I'll put this in the queue for part 3 of the in-moztrap? sprint for issues QA found late in the cycle.

Comment 62

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/09b077922272

Comment 63

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

Using the steps from comment 0 I sent an MMS message from Open C 1.4 and the message took 8 mins to send. However if an MMS is sent directly from the Messages app it takes only around 30 seconds to send


1.4 Environmental Variables:
Device: Open_C 1.4
BuildID: 20140522000200
Gaia: 233dd43b3b976e66a619dbc1b4044ed1e3ca3e34
Gecko: c3c0c57daef8
Version: 30.0
Firmware Version: P821A10V1.0.0B06_LOG_DL

Comment 64

[Julien Wajsberg [:julienw]]

It doesn't really make sense, there is no difference between a MMS sent from the Gallery and a MMS sent directly from the Messages app.

If it means the bug is not fixed, can you please clone the bug to another bug?

Comment 65

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

Please also have tcpdump & adb logcat with the instruction in the following link for further analysis.
https://github.com/bevis-tseng/Debug_Tools

Thanks.

Comment 66

[Derek Harris [:DerekH] - Dont need info. Last day 6/5/15]

I am now unable to get this bug to repro after multiple attempts on 3 different devices. Sorry for the confusion. Not really sure how I got it to repro from commment 63


Flame 2.0
2.0 Environmental Variables:
Device: Flame 2.0
BuildID: 20140527040202
Gaia: 6a391274cd436f8f0d1fad2db8c6b4805703259c
Gecko: cbe4f69c2e9c
Version: 32.0a1
Firmware Version: v10G-2


Open C 1.4:
1.4 Environmental Variables:
Device: Open_C 1.4
BuildID: 20140527000202
Gaia: 0542778892a294d224e75af4a76be5d42938bc90
Gecko: d583ae109f54
Version: 30.0
Firmware Version: P821A10V1.0.0B06_LOG_DL


Buri 1.4:
1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140523000202
Gaia: 16f7ef17feb08562aa6a3cfd6d561b2fcca652c0
Gecko: 9cc96d59cc30
Version: 30.0
Firmware Version: v1.2-device.cfg

Comment 67

[bmorgan]

1.3 Buri: Waited 10 minutes, MMS was not sent while WiFi and Data turned off.

1.4 Buri: MMS sent without problem while WiFi and Data turned off.

2.0 Flame: MMS was not sent while WiFi and Data turned off, timed out after 5 minutes.


1.3 Environmental Variables:
Device: Buri 1.3 MOZ
BuildID: 20140528024003
Gaia: 0ce948e378cab7ed3db20231281dd7ca2eb99779
Gecko: ce0dd450bffb
Version: 28.0
Firmware Version: v1.2-device.cfg

1.4 Environmental Variables:
Device: Buri 1.4 MOZ
BuildID: 20140529000204
Gaia: 7bc1c15c67661a0b8e35f18f15a9d03d1d2cfcd5
Gecko: 2181cac4d0fc
Version: 30.0
Firmware Version: v1.2-device.cfg

2.0 Environmental Variables:
Device: Flame 2.0 MOZ
BuildID: 20140529040201
Gaia: 4142df90c71abdc1e3a87cd37dff1a22d5e38b34
Gecko: 1e712b724d17
Version: 32.0a1
Firmware Version: 10g-2

Comment 68

[Julien Wajsberg [:julienw]]

bmorgan, would you please file another bug for what you see on 1.3 and 2.0?
Thanks

Comment 69

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

The test result looks different in Flame 2.0 in comment 66 (PASSED) and comment 67 (FAILED).

It will be helpful to have 
1. correct STR of the bug 
2. the corresponding logs (adb logcat & tcpdump) for further analysis:
   (See https://github.com/bevis-tseng/Debug_Tools for the step of capturing the logs)

Comment 70

[bmorgan]

(In reply to Julien Wajsberg [:julienw] from comment #68)
> bmorgan, would you please file another bug for what you see on 1.3 and 2.0?
> Thanks

As per request, here is the new bug.  https://bugzilla.mozilla.org/show_bug.cgi?id=1022850