1031656 - [meta] Unable to retrieve MMS on Free Mobile when data is not enabled.

Status: RESOLVED DUPLICATE of bug 1032097

(Firefox OS Graveyard :: RIL, defect)

Description

[:gerard-majax]

On Flame, v2.0 uptodate, I'm unable to get any data connection to work.

STR:
 0. Boot, enable data

Expected:
 Data connection is up ('H' displayed over the signal status)

Actual:
 No data connection is up, no connectivity unabled.

I'm reproducing this with a Free Mobile SIM.

Comment 1

[:gerard-majax]

> 06-28 12:04:25.258  9071  9071 I Gecko   : -*- DataCall[0:free]: Invalid authType undefined
> 06-28 12:04:32.058  9071  9071 I Gecko   : -*- DataCall[0:free]: Invalid authType undefined
> 06-28 12:04:45.988  9071  9071 I Gecko   : -*- DataCall[0:free]: Invalid authType undefined
> 06-28 12:05:06.678  9071  9071 I Gecko   : -*- DataCall[0:free]: Invalid authType undefined
> 06-28 12:05:37.948  9071  9071 I Gecko   : -*- DataCall[0:free]: Invalid authType undefined

Comment 2

[:gerard-majax]

> 06-28 12:50:58.551  5327  5327 I Gecko   : -*- NetworkManager: Failed to resolve 'mms.free.fr', exception: [Exception... "Component returned failure code: 0x804b001e (NS_ERROR_UNKNOWN_HOST) [nsIDNSService.resolve]"  nsresult: "0x804b001e (NS_ERROR_UNKNOWN_HOST)"  location: "JS frame :: jar:file:///system/b2g/omni.ja!/components/NetworkManager.js :: NetworkManager.prototype.resolveHostname :: line 654"  data: no]

Comment 3

[:gerard-majax]

Attachment: mms-free.log

STR:
 0. Receive a MMS
 1. Make sure data and mms connections are properly configured
 2. Make sure you have no data nor wifi connection enabled
 3. Tap "Retrieve" in Messages

Expected:
 MMS is downloaded

Actual:
 MMS is never downloaded

Attached is the logcat filtered for "DataCall|DataConnection|NetworkManager|NetworkService". It seems that the NetworkManager is at fault there:

> 06-28 12:50:58.471  5327  5327 I Gecko   : -*- NetworkService: Going DNS to rmnet0
> 06-28 12:50:58.541  5327  5327 I Gecko   : -*- NetworkManager: Adding mmsproxy and/or mmsc route for rmnet0
> 06-28 12:50:58.551  5327  5327 I Gecko   : -*- NetworkManager: Failed to resolve 'mms.free.fr', exception: [Exception... "Component returned failure code: 0x804b001e (NS_ERROR_UNKNOWN_HOST) [nsIDNSService.resolve]"  nsresult: "0x804b001e (NS_ERROR_UNKNOWN_HOST)"  location: "JS frame :: jar:file:///system/b2g/omni.ja!/components/NetworkManager.js :: NetworkManager.prototype.resolveHostname :: line 654"  data: no]
> 06-28 12:50:58.551  5327  5327 I Gecko   : -*- NetworkManager: No valid hostnames can be added. Stop adding host route.

The hostname itself can be resolved properly at the same time on other devices. It would look like we are removing the default route via rmnet0 (which at this point is the connection to the mms APN) before we completed DNS resolution.

Comment 4

[:gerard-majax]

Hard coding the MMSC IP address, and running wireshark, I see no network request being done at all.

Comment 5

[:gerard-majax]

Network routes are properly setup:
> # cat /proc/net/route                                             
> Iface	Destination	Gateway 	Flags	RefCnt	Use	Metric	Mask		MTU	Window	IRTT                                                       
> wlan0	00000000	FE01A8C0	0003	0	0	0	00000000	0	0	0                                                                              
> rmnet0	0042FD0A	00000000	0001	0	0	0	80FFFFFF	0	0	0                                                                             
> wlan0	0001A8C0	00000000	0001	0	0	322	00FFFFFF	0	0	0                                                                            
> rmnet0	E1281BD4	4142FD0A	0007	0	0	0	FFFFFFFF	0	0	0                                                                             
> rmnet0	F0281BD4	4142FD0A	0007	0	0	0	FFFFFFFF	0	0	0                                                                             
> rmnet0	F1281BD4	4142FD0A	0007	0	0	0	FFFFFFFF	0	0	0

Comment 6

[:gerard-majax]

Without WiFi:

> # cat /proc/net/route                                             
> Iface	Destination	Gateway 	Flags	RefCnt	Use	Metric	Mask		MTU	Window	IRTT                                                       
> rmnet0	E890FD0A	00000000	0001	0	0	0	FCFFFFFF	0	0	0                                                                             
> rmnet0	E1281BD4	E990FD0A	0007	0	0	0	FFFFFFFF	0	0	0                                                                             
> rmnet0	F0281BD4	E990FD0A	0007	0	0	0	FFFFFFFF	0	0	0                                                                             
> rmnet0	F1281BD4	E990FD0A	0007	0	0	0	FFFFFFFF	0	0	0                                                                             

So the route is: 10.253.144.233 but my IP is: 10.253.144.234

Comment 7

[:gerard-majax]

> 06-28 13:14:57.976  7312  7312 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"status":0,"suggestedRetryTime":-1,"cid":"0","active":2,"type":"IP","ifname":"rmnet0","addresses":["10.253.144.234/30"],"dnses":["212.27.40.240","212.27.40.241"],"gateways":["10.253.144.233"],"state":3,"radioTech":2,"apn":"mmsfree","user":"","passwd":"","chappap":3,"pdptype":"IP","rilMessageType":"datacallstatechange","rilMessageClientId":0}

Doing a tcpdump in parallel show no trafic at all when there is no data nor WiFi call. When there is a parallel WiFi connection, tcpdump shows that the MMS APN data goes through the WiFi connection instead of the MMS APN.

Comment 8

[:gerard-majax]

Okay, I see some inconsistency:

In logcat/RIL:
> 06-28 13:32:49.832 11613 11613 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"status":0,"suggestedRetryTime":-1,"cid":"0","active":2,"type":"IP","ifname":"rmnet0","addresses":["10.255.167.149/30"],"dnses":["212.27.40.240","212.27.40.241"],"gateways":["10.255.167.150"],"state":1,"radioTech":2,"apn":"mmsfree","user":"","passwd":"","chappap":3,"pdptype":"IP","rilMessageType":"datacallstatechange","rilMessageClientId":0}

netcfg output:
> # netcfg
> rmnet0   UP                              10.255.167.149/30  0x00000041 00:00:00:00:00:00

ip route:
> # ip route                                                        
> 10.255.167.148/30 dev rmnet0  proto kernel  scope link  src 10.255.167.149 
> 212.27.40.225 via 10.255.167.150 dev rmnet0 
> 212.27.40.240 via 10.255.167.150 dev rmnet0 
> 212.27.40.241 via 10.255.167.150 dev rmnet0

So the configured IP address is good (10.255.167.149), the recorded gateways for DNS (212.27.40.240, 212.27.40.241) and MMSC (212.27.40.225) are configured via the proper gateway received by RIL (10.255.167.150).

But the route seems strange: 10.255.167.148/30. As far as I remember, this points to 10.255.167.148 and not 10.255.167.150.

Comment 9

[:gerard-majax]

Sending MMS, however, works.

Comment 10

[:gerard-majax]

I'm reproducing this also on my dogfooding Nexus S, on which it was working at some point.

Comment 11

[:gerard-majax]

FYI, the SIM card in my Nexus S is from the same carrier. Without data connection (different APN from MMS), I cannot get the MMS downloaded. If I mount data connectivity, it is then able to get it on both devices.

Comment 12

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

We don't work on MozRIL on Flame anymore. Please re-open if it's replicable on any of other devices. Or, change the component to Vendcom.

Comment 13

[:gerard-majax]

Nexus S is not MozRIL/Flame and reproduces the issue. I don't have any other device to reproduce on.

Comment 14

[:gerard-majax]

(In reply to Alexandre LISSY :gerard-majax from comment #11)
> FYI, the SIM card in my Nexus S is from the same carrier. Without data
> connection (different APN from MMS), I cannot get the MMS downloaded. If I
> mount data connectivity, it is then able to get it on both devices.

And of course, there is no issue at all on Android.

Comment 15

[:gerard-majax]

Natalia, we will want to check this also on v1.3 ...

Comment 16

[Jason Smith [:jsmith]]

(In reply to Alexandre LISSY :gerard-majax from comment #15)
> Natalia, we will want to check this also on v1.3 ...

It's probably also worth checking Buri here.

Comment 17

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

Looks similar to bug 1029453 under the same carrier Free.

Comment 18

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

After checking the APN settings of Free, I just realized that there is one scenario that we don't take into consideration for setting the routing tables by only according the APN settings of the established data connection:
1. There is no MMS Proxy provided by the carrier.
2. The host address of the URL to be retrieved is not the same to the MMS address that we have added into routing table according to the MMS APN settings.

In this case, it is possible that there is no tcp traffic going out as mentioned in comment 7 when there is no data nor WiFi call and mms traffic will be sent via Wifi when Wifi is enabled. (Default route is enabled).

Comment 19

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

It will be helpful if we can enabled all log-flags (ril, mms, network) for further analysis:
https://github.com/bevis-tseng/Debug_Tools/blob/master/enable_debug_flags.sh

Comment 20

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

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #17)
> Looks similar to bug 1029453 under the same carrier Free.
Not related to bug 1029453. 
Bug 1029453 is more related to not able to receiving a MMS notification sent when the MMS is sent by Open C device.

Comment 21

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

Symptom in comment 3 looks related to bug 992772.

Comment 22

[:gerard-majax]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #19)
> It will be helpful if we can enabled all log-flags (ril, mms, network) for
> further analysis:
> https://github.com/bevis-tseng/Debug_Tools/blob/master/enable_debug_flags.sh

You already have all RIL/Network logs we can even think of.

Comment 23

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

(In reply to Alexandre LISSY :gerard-majax from comment #22)
> (In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #19)
> > It will be helpful if we can enabled all log-flags (ril, mms, network) for
> > further analysis:
> > https://github.com/bevis-tseng/Debug_Tools/blob/master/enable_debug_flags.sh
> 
> You already have all RIL/Network logs we can even think of.
Oh, but we don't have the MMS related logs enabled in the attached log to double confirm what I mentioned in comment 18 that the host address of the url to be retrieved is not the same to the mmsc ip-address "212.27.40.225". :(

Comment 24

[:gerard-majax]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #23)
> (In reply to Alexandre LISSY :gerard-majax from comment #22)
> > (In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #19)
> > > It will be helpful if we can enabled all log-flags (ril, mms, network) for
> > > further analysis:
> > > https://github.com/bevis-tseng/Debug_Tools/blob/master/enable_debug_flags.sh
> > 
> > You already have all RIL/Network logs we can even think of.
> Oh, but we don't have the MMS related logs enabled in the attached log to
> double confirm what I mentioned in comment 18 that the host address of the
> url to be retrieved is not the same to the mmsc ip-address "212.27.40.225".
> :(

MMSC DNS resolution and routing table is documented in comment 8. Yes, there is no MMS debug provided, because I had no time to generate some for now. Having to edit prefs really really makes it very irritating to help debugging, though.

Comment 25

[:gerard-majax]

Attachment: mms-zte_openc_free.log

Here is the logcat when reproducing the very same issue on a brand new OPEN C with partner's build.

Natalia, can you share the build info for this ROM ?

Comment 26

[Natalia Martinez-Winter]

software version is : FFOS_FR_ZTE_OPENCV1.0.0B01
system version : 1.3.0.0
hardware : P821A10B01
platform version : 28.0
version ID : 20140625152014
Git info : 2014-06-27 08:12:34 unknown

Comment 27

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

(In reply to Alexandre LISSY :gerard-majax from comment #25)
> Created attachment 8447988 [details]
> mms-zte_openc_free.log
> 
> Here is the logcat when reproducing the very same issue on a brand new OPEN
> C with partner's build.

There is no mms notification coming into the device.
It looks the same to what we saw in bug 1029453.

Comment 28

[:gerard-majax]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #27)
> (In reply to Alexandre LISSY :gerard-majax from comment #25)
> > Created attachment 8447988 [details]
> > mms-zte_openc_free.log
> > 
> > Here is the logcat when reproducing the very same issue on a brand new OPEN
> > C with partner's build.
> 
> There is no mms notification coming into the device.
> It looks the same to what we saw in bug 1029453.

There is MMS notification, since I got the message "You have a MMS, click here to download". That's after triggering the download that we cannot get it.

Comment 29

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

(In reply to Alexandre LISSY :gerard-majax from comment #28)
> There is MMS notification, since I got the message "You have a MMS, click
> here to download". That's after triggering the download that we cannot get
> it.
Thanks for clarifying this.

That means we didn't capture it into the log. :(
Otherwise, we will see "receiveWapPush" if Mms log is enabled:
http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/annotate/d988603b9bbd/dom/mobilemessage/src/gonk/MmsService.js#l2468

Comment 30

[:gerard-majax]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #29)
> (In reply to Alexandre LISSY :gerard-majax from comment #28)
> > There is MMS notification, since I got the message "You have a MMS, click
> > here to download". That's after triggering the download that we cannot get
> > it.
> Thanks for clarifying this.
> 
> That means we didn't capture it into the log. :(
> Otherwise, we will see "receiveWapPush" if Mms log is enabled:
> http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/annotate/d988603b9bbd/dom/
> mobilemessage/src/gonk/MmsService.js#l2468

That's not the issue, I started the logcat after receiving the MMS. I cannot enable any specific logging on this device: production ROM, we don't have root access, and no userdebug alternative of this ROM. So until I can get my hands on something with root and v1.3 ...

Comment 31

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: remove regression keyword given that this happens on 1.3, 1.3T, 1.4, 2.0, 2.1.
This shouldn't be a release blocker so let's put in backlog.

Comment 32

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

Wesley: I'm quite sure it will be a cert blocker for some partners as I've seen other issues about Free Mobile from partners.

Comment 33

[:gerard-majax]

Attachment: mms.debugging.enabled

This is the logcat output with mms.debugging.enabled on Nexus S, while reproducing the issue.

Comment 34

[:gerard-majax]

Attachment: /proc/net/route

And the matching routing table on the device when trying to download the MMS.

Comment 35

[:gerard-majax]

As of attachement 8449387 and attachment 8449388 [details], I could see that our MMS Gecko code is trying to download from http://213.228.2.8/. This is not the MMSC registered in our config. It also does not match my android device config.

However, hardcoding this host as the MMSC in our config, I can download the MMS properly.

Vicamo, does the log give your any input ?

Comment 36

[:gerard-majax]

I had a quick look, so the URL is retrieve from the message's x-mms-content-location value. I think the proper fix here would be to add a specific route for this host also.

Comment 37

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

(In reply to Alexandre LISSY :gerard-majax from comment #35)
> As of attachement 8449387 and attachment 8449388 [details], I could see that
> our MMS Gecko code is trying to download from http://213.228.2.8/. This is
> not the MMSC registered in our config. It also does not match my android
> device config.
> 
> However, hardcoding this host as the MMSC in our config, I can download the
> MMS properly.

Looks the same to what have been mentioned in comment 18 and new bug 1032097 has been filed to address this.

Comment 38

[:gerard-majax]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #37)
> (In reply to Alexandre LISSY :gerard-majax from comment #35)
> > As of attachement 8449387 and attachment 8449388 [details], I could see that
> > our MMS Gecko code is trying to download from http://213.228.2.8/. This is
> > not the MMSC registered in our config. It also does not match my android
> > device config.
> > 
> > However, hardcoding this host as the MMSC in our config, I can download the
> > MMS properly.
> 
> Looks the same to what have been mentioned in comment 18 and new bug 1032097
> has been filed to address this.

Thanks. Will you start working on this soon ? We will need a fix asap that we can apply on v1.3.

Comment 39

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

This case happens in carrier Free that we didn't consider well in current design.
It will be a major design change between NetworkManager/MmsService in gecko for both bug 992772 and bug 1032097.
bug 992772 can be workaround if the mmsc(http://mms.free.fr) in apn is replaced with its ip-address (http://212.27.40.225).

NI EPM to triage 1.3? again.

Comment 40

[:gerard-majax]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #39)
> This case happens in carrier Free that we didn't consider well in current
> design.
> It will be a major design change between NetworkManager/MmsService in gecko
> for both bug 992772 and bug 1032097.
> bug 992772 can be workaround if the mmsc(http://mms.free.fr) in apn is
> replaced with its ip-address (http://212.27.40.225).
> 
> NI EPM to triage 1.3? again.

I know partner also hit bug 992772 on their 1.3 image. I ran into this issue myself when debugging this on master.

I haven't had a precise look at bug 992772 but for bug 1032097 I don't get the rationale ; as I asked in bug 1032097 comment 1, can't you just make a call to the NetworkService component to add a route from the MmsService ? Why a new API ?

Comment 41

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

(In reply to Alexandre LISSY :gerard-majax from comment #40)
> (In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #39)
> > This case happens in carrier Free that we didn't consider well in current
> > design.
> > It will be a major design change between NetworkManager/MmsService in gecko
> > for both bug 992772 and bug 1032097.
> > bug 992772 can be workaround if the mmsc(http://mms.free.fr) in apn is
> > replaced with its ip-address (http://212.27.40.225).
> > 
> > NI EPM to triage 1.3? again.
> 
> I know partner also hit bug 992772 on their 1.3 image. I ran into this issue
> myself when debugging this on master.
> 
> I haven't had a precise look at bug 992772 but for bug 1032097 I don't get
> the rationale ; as I asked in bug 1032097 comment 1, can't you just make a
> call to the NetworkService component to add a route from the MmsService ?
> Why a new API ?

bug 992772 is to try & error if there is anything we need to change in the MMS-Send-Request PDU to allow the MMSC to send the MMS notification to the receiving party because we didn't see anything wrong from the MO device.

For bug 1032097, I thinked more about whether we have to manage all the resolving/add/removing extra host from the download url to route by the NetworkManager.
But as you mentioned, MmsService can also handle this per transaction with NetworkService instead.
Thanks for your suggestion. :)

Comment 42

[:gerard-majax]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #41)

[...]

> 
> For bug 1032097, I thinked more about whether we have to manage all the
> resolving/add/removing extra host from the download url to route by the
> NetworkManager.
> But as you mentioned, MmsService can also handle this per transaction with
> NetworkService instead.
> Thanks for your suggestion. :)

You're welcome. I suspect it implies that the fix will be simpler, in this case :)

Comment 43

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: shouldn't block previous release. Uplift should be upon request if partner called out this as cert blocker.

Comment 44

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

We should _at least_ consider this for the current release.

This is a _huge_ missing functionality happening on some carriers (not just Free Mobile). There is _no_ workaround to this.

Comment 45

[bhavana bajaj [:bajaj]]

(In reply to Julien Wajsberg [:julienw] from comment #44)
> We should _at least_ consider this for the current release.
> 
> This is a _huge_ missing functionality happening on some carriers (not just
> Free Mobile). There is _no_ workaround to this.

Do you think is is MozRIL specific or something that can happen with CAF RIl as well? Any other carriers we already know that will run into this. QA's testing has never shown this behavior..

Comment 46

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

(In reply to bhavana bajaj [:bajaj] [NOT reading Bugmail, needInfo please] from comment #45)
> Do you think is is MozRIL specific or something that can happen with CAF RIl
> as well? Any other carriers we already know that will run into this. QA's
> testing has never shown this behavior..

There are 2 dependency of this bug:
1. In the MMS configuration of Free, it seems that the mmsc is not reachable from default network.
   bug 992772 was filed to address the problem of resolving mmsc/proxy with selected network interface
   like MMS data connection.
   The short-term workaround of this bug is to have the ip address of mmsc/proxy in the MMS APN settings.
2. bug 1032097 was filed to address the problem mentioned in comment 18 that the hostname of download url
   is not related to the mmsc/proxy address in the MMS APN settings.
   In this case, the routing is undefined. This cause MMS retrieval not functional.
   However, Free is the only known carrier so far that will run into this scenario.

Maybe we should triage bug 992772 and bug 1032097 accordingly instead.

Comment 47

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

Note that a lot of employees in the Paris office use Free Mobile. That would impair dogfooding if this doesn't work properly.

Another piece of information: this seemed to work in the past (Alexandre may be able to say more).

Bevis, do you know if the issue would happen with the commmercial RIL (is CAF RIL the same thing?) ?

Comment 48

[Jason Smith [:jsmith]]

Triage - not a blocking issue. 1.3 included France as a target market in certification testing. During certification testing in France, this was not called out as a certification blocker. On that regard, we do not have evidence that our partners are concerned about this right now. We can look into fixing this to allow for using this SIM in France dogfooding.

Comment 49

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

(In reply to Julien Wajsberg [:julienw] from comment #47)
> Note that a lot of employees in the Paris office use Free Mobile. That would
> impair dogfooding if this doesn't work properly.
> 
> Another piece of information: this seemed to work in the past (Alexandre may
> be able to say more).
This design defect exists from the beginning without taking the hostname/address of the download URL into consideration of the routing for MMS transaction.
The only possibility I can imagine so far is that the host address of the download URL from Free was changed recently.
> 
> Bevis, do you know if the issue would happen with the commmercial RIL (is
> CAF RIL the same thing?) ?
Yes, the logic is inside NetworkManager & MmsService.
there shall be no difference between Moz RIL and Commercial RIL.

Comment 50

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

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #49)
> (In reply to Julien Wajsberg [:julienw] from comment #47)
> > Note that a lot of employees in the Paris office use Free Mobile. That would
> > impair dogfooding if this doesn't work properly.
> > 
> > Another piece of information: this seemed to work in the past (Alexandre may
> > be able to say more).
> This design defect exists from the beginning without taking the
> hostname/address of the download URL into consideration of the routing for
> MMS transaction.
> The only possibility I can imagine so far is that the host address of the
> download URL from Free was changed recently.
Another possibility is that the data connection is enabled (which enables the default route) and the host of the download url is reachable from default route.

Comment 51

[:gerard-majax]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #50)
> (In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #49)
> > (In reply to Julien Wajsberg [:julienw] from comment #47)
> > > Note that a lot of employees in the Paris office use Free Mobile. That would
> > > impair dogfooding if this doesn't work properly.
> > > 
> > > Another piece of information: this seemed to work in the past (Alexandre may
> > > be able to say more).
> > This design defect exists from the beginning without taking the
> > hostname/address of the download URL into consideration of the routing for
> > MMS transaction.
> > The only possibility I can imagine so far is that the host address of the
> > download URL from Free was changed recently.
> Another possibility is that the data connection is enabled (which enables
> the default route) and the host of the download url is reachable from
> default route.

I would bet it's both. I remember testing this successfully at the very first beginning of MMS landind, on Free Mobile. Then a couple of weeks ago it broke, but I did not noticed because:
 - for some long time, I kept dogfooding on a mid 1.1-1.2 build and I had no time to update (gralloc breakage on Nexus S), this made me believe the issue was a bad build
 - often, I had data enabled when retrieving MMS
 - I don't use MMS a lot

This explains why we may have missed it easily.

As you said, also, enabling data makes the packets to be sent via the default route, and luckily this gets accepted.

Comment 52

[lenod.lenod]

Just to confirm that I am affected with this bug (sending MMS is ok but not receiving), with Free Mobile on a 1.3.0.0-prerelease Flame.

Comment 53

[Xavier Laurent]

Using 2.0 on a ZTE Open C, I'm able to receive MMS (and attached picture) with Free. My build is 2 weeks old, but I don't remember ever having MMS troubles, also I don't use them much.

Comment 54

[:gerard-majax]

(In reply to Xavier Laurent from comment #53)
> Using 2.0 on a ZTE Open C, I'm able to receive MMS (and attached picture)
> with Free. My build is 2 weeks old, but I don't remember ever having MMS
> troubles, also I don't use them much.

That's surprising ... Are you sure you don't have data connected at the time you retrieve the MMS ?

Comment 55

[Xavier Laurent]

Oops sorry, I indeed always have data on

Comment 56

[:gerard-majax]

Had feedback and a look at the packets sent over wire.

The content type of the payload is:
> application/vnd.wap.multipart.related; type=application/smil; start="<smil>

Please note this '"', it may be the root cause of this.

Comment 57

[:gerard-majax]

(In reply to Alexandre LISSY :gerard-majax from comment #56)
> Had feedback and a look at the packets sent over wire.
> 
> The content type of the payload is:
> > application/vnd.wap.multipart.related; type=application/smil; start="<smil>
> 
> Please note this '"', it may be the root cause of this.

And please note this comment was not for the proper bug :)

Comment 58

[:gerard-majax]

(In reply to Jason Smith [:jsmith] from comment #48)
> Triage - not a blocking issue. 1.3 included France as a target market in
> certification testing. During certification testing in France, this was not
> called out as a certification blocker. On that regard, we do not have
> evidence that our partners are concerned about this right now. We can look
> into fixing this to allow for using this SIM in France dogfooding.

So having MMS broken for at least one carrier (and potentially more considering the bug, if other changes their MMS payload/architecture) is not a certification blocker ?

Comment 59

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

Another fact: Free Mobile is the cheapest carrier in France. It's also quite worshipped by techy people. This means this carrier is more used by our 2 target customer groups.

Comment 60

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

Note that Free Mobile has more than 8M subscribers in France.

Comment 61

[Anthony Ricaud (:rik)]

This is a dogfooding issue for several people in Paris.

Comment 62

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

According to comment 46, we need both bug 1032097 and bug 992772 to support retrieve MMS on free mobile.
Mark this as a meta bug tracking all related fixes.

Comment 63

[:gerard-majax]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #62)
> According to comment 46, we need both bug 1032097 and bug 992772 to support
> retrieve MMS on free mobile.
> Mark this as a meta bug tracking all related fixes.

Vance, just to make you aware, for the MR of ZTE OPEN C in France following its launch.

Comment 64

[naabster]

(In reply to lenod.lenod from comment #52)
> Just to confirm that I am affected with this bug (sending MMS is ok but not
> receiving), with Free Mobile on a 1.3.0.0-prerelease Flame.

Hello,

On my ZTE OPENC with FirefoxOS 1.3 (FFOS_EU_EBAY_OPENCV1.0.0B01) it the same !! I can sending MMS but not receving !

Comment 65

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

See [1]: the french community support forum where this issue has been asked already.

[1] http://forums.mozfr.org/viewtopic.php?f=35&t=119228

Comment 66

[:gerard-majax]

Bug 1043114 has been fixed, this is good, but I when do we plan to work on a solution for v1.3 for partner? Their MR release window will not be opened forever :(

Comment 67

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

(In reply to Alexandre LISSY :gerard-majax from comment #66)
> Bug 1043114 has been fixed, this is good, but I when do we plan to work on a
> solution for v1.3 for partner? Their MR release window will not be opened
> forever :(

Bug 1032097 is also required and I am going to work on it this week.
I didn't see any plan to uplift to 1.3 yet.

Comment 68

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

According to the previous triage results, this shouldn't be blocking the previous release, such as v.1.3 and v1.4. Based on that, I don't think we plan to work on v1.3 for this issue. Instead we are aiming at resolving this in a coming release. Bevis and Henry are working on the remaining dependent bugs.

Comment 69

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

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #68)
> According to the previous triage results, this shouldn't be blocking the
> previous release, such as v.1.3 and v1.4. Based on that, I don't think we
> plan to work on v1.3 for this issue. Instead we are aiming at resolving this
> in a coming release. Bevis and Henry are working on the remaining dependent
> bugs.

Please be informed that bug 992772 has the dependency to AOSP JB 4.3 in |netd| to be able to accept |getaddrinfo| request with specified |iface| as mentioned in comment 7 of bug 992772.
The workaround for bug 992772 is to have ip-address specified in the mms apn settings instead of the hostname.

Comment 70

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

There are 2 known reasons for being not able to receive a MMS in Free Mobile:
One is addressed in bug 1029453 and has been fixed in network side.
The other one is mentioned in comment 18 and the solution will be provided in bug 1032097.
(The problem occurs when data is off.)

Update the title accordingly.

Comment 71

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #69)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #68)
> > According to the previous triage results, this shouldn't be blocking the
> > previous release, such as v.1.3 and v1.4. Based on that, I don't think we
> > plan to work on v1.3 for this issue. Instead we are aiming at resolving this
> > in a coming release. Bevis and Henry are working on the remaining dependent
> > bugs.
> 
> Please be informed that bug 992772 has the dependency to AOSP JB 4.3 in
> |netd| to be able to accept |getaddrinfo| request with specified |iface| as
> mentioned in comment 7 of bug 992772.
> The workaround for bug 992772 is to have ip-address specified in the mms apn
> settings instead of the hostname.

Yup... a solution to bug 992772 highly depends on the version of AOSP. Just talked to Henry, I know he is also aware of that and working on the version issue.

Comment 72

[:gerard-majax]

I was referring specifically to the fix for bug 1032097. This one needs to be available for partner for v1.3 branch.

Comment 73

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

(In reply to Alexandre LISSY :gerard-majax from comment #72)
> I was referring specifically to the fix for bug 1032097. This one needs to
> be available for partner for v1.3 branch.

If that's the case, would you mind nominating on that bug again, so that hopefully everyone could have a clear scope?

Comment 74

[:gerard-majax]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #73)
> (In reply to Alexandre LISSY :gerard-majax from comment #72)
> > I was referring specifically to the fix for bug 1032097. This one needs to
> > be available for partner for v1.3 branch.
> 
> If that's the case, would you mind nominating on that bug again, so that
> hopefully everyone could have a clear scope?

There is no v1.3 blocking flag anymore.

Comment 75

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

(In reply to Alexandre LISSY :gerard-majax from comment #74)
> (In reply to Hsin-Yi Tsai [:hsinyi] from comment #73)
> > (In reply to Alexandre LISSY :gerard-majax from comment #72)
> > > I was referring specifically to the fix for bug 1032097. This one needs to
> > > be available for partner for v1.3 branch.
> > 
> > If that's the case, would you mind nominating on that bug again, so that
> > hopefully everyone could have a clear scope?
> 
> There is no v1.3 blocking flag anymore.

Okay... I didn't notice that :P
So, that seems the only solution is we keep working on m-c. And once the fix is ready, partner could cherry pick the fix if they want?

Comment 76

[:gerard-majax]

Sure they can cherry-pick. If we fix this in time.

Comment 77

[Natalia Martinez-Winter]

Hi,

after only a few weeks of sales, we're starting to see more and more customer's feedback about this issue with MMS with Free, to give you an example in this french forum : http://forums.mozfr.org/viewtopic.php?f=35&t=119228&sid=d99796b25ec702d595eba8666ae9d22b
see also attached, this issue is the most "popular" in the forum.
Your help to solve this is sorely needed.
Vance, can you please check with ZTE if a fix can be included in the MR asap ?
Tahnks a lot !

Comment 78

[Natalia Martinez-Winter]

Attachment: french forum - MMS Free bug

Comment 79

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

According to the forum, looks like it is the old MT MMS problem. For that problem Mozilla/ZTE didn't check in any patch, the modification is done in server side. ZET just feedback that the modification of server side is done in 7/27, they are now double checking again with Free to see why still there is a MT MMS problem

Thanks

Vance

Comment 80

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

On a closer look of the forum, it seems like the main problem is not about MT MMS but something relevant to APN setting. I notice that Julien already provided some comments on the forum. As I remembered, the APN problem is not easy to fix. Mozilla is working on that but it won't be ready anytime soon. I am checking with ZTE to see if there is a workaround for that, or at least they should help to provide clear instruction somewhere in their website to tell users how to correctly set the APN for Free operator

Thanks

Comment 81

[Natalia Martinez-Winter]

Vance,

I think there might be a confusion here, just to recap the several issues related to MMS with Free, we have faced 3 bugs :
1) bug to send an MMS due to DNS resolution race : bug 992772 (almost ok = workaround found with hardcoded address for MMSC)
2) bug to send an MMS (from a FREE sim card) to other operators : fixed on server side
3) bug to receive an MMS with a FREE sim card (from any operator).  bug 1032097

The issue the forum is related to concerns the *last* bug, this is the one I'd really like to find a solution to. (for 1.3 ideally , to be included in the MR).

Hope this clarifies the request. Could you please dig into solving this ?

Comment 82

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

Hi Natalia, 

The last issue you mentioned is the same as the one I talked about in Comment#80. The patches of that is huge, and i think it is quite risky to put it into 1.3 at current stage. 

But nevertheless let's wait for experts' comments. ni Vicamo, Edger and Bevis to see if it is possible to include the fix of 1032097 to 1.3

Thanks

Comment 83

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

Hi Vance,

For bug 1032097, there is dependency to Bug 1043114 which is to refine the add/removeHostRoute APIs in NetworkUtils/NetWorkService/NetworkManager.

The risk to have solution of bug 1032097 for 1.3 branch is that
1. There is is a big re-factor from 1.3 to 1.4 to re-implement net_work.js (1.3) to (NetworkUtils).
2. That means we have to re-write the implementation of bug 1043114 for 1.3 branch.

The rough effort for this is to have 2 weeks for implementation/review and 1 week for testing.

Comment 84

[:gerard-majax]

Bevis, I know this bug is a big work. However, not being able to have a workaround for 1.3 and 2.0 is really a bad thing, regarding the consequences of this bug. I remember that you told me there would be a way to hack a workaround that would be not too much work, so easy to test for regressions. Could we please try to focus on this for v1.3 and v2.0 so that partners could at least provide a device that just works?

Comment 85

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

Hi all -

Since the MMS can be downloaded successfully if the data connection is on, at least there is a way for users to retrieve MMS. I will reach out to ZTE to see if they can have a Free MMS FAQ somewhere on the web to explain how to download the MMS. And they need to have customers-support people to provide helps on forums as well.

And I will also check with ZTE about the Open C MR plan. I will suggest ZTE that MR should wait for this patch

Thanks

Vance

Comment 86

[Natalia Martinez-Winter]

just a small comment about the impact of this "workaround" :
in France , Free mobile sells the cheapest tariff plan at 2€ monthly which includes 2h of voice usage, unlimited SMS/MMS and 50Mo of data. People who buy it most of the times only use voice and SMS/MMS and they disable data (for fear of having to very quickly pay for it, and use wifi for data).
and we're selling the Open C in retail stores at a very attractive price, there are good chances that people who will choose this device (because it's cheap) will be Free mobile customers, probably de-activating data on their phone.
Ideally, receiving MMS should work without having to turn on data, as it works with any other phone.

Comment 87

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

(In reply to Alexandre LISSY :gerard-majax from comment #84)
> Bevis, I know this bug is a big work. However, not being able to have a
> workaround for 1.3 and 2.0 is really a bad thing, regarding the consequences
> of this bug. I remember that you told me there would be a way to hack a
> workaround that would be not too much work, so easy to test for regressions.
> Could we please try to focus on this for v1.3 and v2.0 so that partners
> could at least provide a device that just works?

I'll work on the patch for 1.3 for sure since ZTE devices has been sold to Free Mobile which brings bad UX as mentioned in comment 86.
For the solution on 1.4/2.0, I prefer to nominate bug 1032097 & Bug 1043114 to see the necessity of landing the fix.

Comment 88

[[e-mail]]

I have got a ZTE Open C under Firefox OS 1.3 version. My provider is Free Mobile and I've got this bug with the MMS. If you're searching for someone who can do a customers-support to provide helps on forums (as I alreaady do on Geckozone, http://forums.mozfr.org/, Twitter and Diaspora), join me.

Comment 89

[:gerard-majax]

Bevis, do you have any news on 1.3 patch for ZTE and 1.4/2.0 uplift?

Comment 90

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

(In reply to Alexandre LISSY :gerard-majax from comment #89)
> Bevis, do you have any news on 1.3 patch for ZTE and 1.4/2.0 uplift?

Hi Lissy,

The corresponding fix has been addressed in bug 1032097.
Because 1.3v is end of life, I am still working on it for 1.3 locally to provide the fix when ZTE is needed.
Uplifting for 1.4 was nominated but has been rejected to reduce the risk since this issue can only be happened in Free@Franch.

Comment 91

[alexis]

Hi

"I am still working on it for 1.3 locally to provide the fix when ZTE is needed."
French ZTE support know that ?

I don't think...they give old link (http://mobile.free.fr/assistance/65.html) to config MMS with free on android on a FF_OS forum !
http://blog-libre.org/ask/index.php?qa=65&qa_1=zte-open-c-et-les-mises-%C3%A0-jour-officielles&show=409#c409

Please, don't forget us, there is really many user with free in france...
If you need some help to put the pressure on free (I think you can count on french community users) : an exemple, the subscription is to 0€ with 50Mo data for people who have internet with free... 15€ with unlimited datas ... so many people stay on 0€ because data not working...but me, and many others i think, waiting for increased...

Comment 92

[chencong]

Hi Vance & Bevis,

Please give the patch to fix this issue ASAP, we need to build MR version.
Thanks!

Comment 93

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

Hi Chen Cong -

The patch can be found here:

https://bug1032097.bugzilla.mozilla.org/attachment.cgi?id=8492952

https://bug1032097.bugzilla.mozilla.org/attachment.cgi?id=8492954

https://bug1032097.bugzilla.mozilla.org/attachment.cgi?id=8492955

There are 3 parts of the patches, please do cherry-pick all

Thanks

Comment 94

[Julien Wajsberg [:julienw] (PTO -> Jul 24)]

\o/ Thanks so much Bevis :)

Comment 95

[:gerard-majax]

Bevis, next time you come to Paris we owe you some awesome present ! Thanks !

Comment 96

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

Thanks!
It's my pleasure to have these work with you guys to provide better FFOS experience to France! \o/