Closed Bug 1152568 Opened 9 years ago Closed 9 years ago

MMS Proxy routing problem in L when only MMS data call up


(Firefox OS Graveyard :: RIL, defect)

Gonk (Firefox OS)
Not set



blocking-b2g 2.2+


(Reporter: pgravel, Assigned: bevis)



(Whiteboard: [caf priority: p2][CR 820235])


(1 file)

Attached file mms_fail.log
Getting an error resolve MMS proxy when trying to send an MMS.

Steps to reproduce
1. Ensure MMS apn different than Data APN (not necessary but helps isolate mms connection)
2. Have data down
3. Try to send a MMS
4. MMS will fail with error: "Failed to ensureRouting: Error: Failed to resolve '', with status: 2152398878"
5. Retrying to send will keep failing with the same error

If I register the newly created data call as NETWORK_TYPE_MOBILE instead of NETWORK_TYPE_MOBILE_MMS, then the MMS will send successfully. As such, my current guess is that secondary data call routing is incorrect in L.

Logs attached.

(note: this is not the same problem as the one I commented on in bug 1126222. With that bug subsequent attempts to send the MMS will work, in this case subsequent attempts will keep failing)
blocking-b2g: --- → 2.2?
QAWanted to see if it can be reproduced on Nexus 5 (L based).
Keywords: qawanted
Works fine on these 2.
- NEXUS-5-L 5.1 master local build
- NEXUS-5-L 5.0 v2.2 PVT

rm qawanted
Keywords: qawanted
Routing looks good:
> 9789:04-08 15:19:54.342   260  2375 D NetworkUtils: Receiving "0 network route legacy 0 add 100 rmnet_data0" command response from netd.
> 9790:04-08 15:19:54.342   260  2375 D NetworkUtils:           ==> Code: 200  Reason: success
> 9802:04-08 15:19:54.352   260  2375 D NetworkUtils: Receiving "0 network route legacy 0 add 100 rmnet_data0" command response from netd.
> 9803:04-08 15:19:54.352   260  2375 D NetworkUtils:           ==> Code: 200  Reason: success

But currently we don't support resolveHostName with the DNS of the specified NetworkInterface yet, netd will always use the dns services of default interface to resolve host name. However, in mms-only case there is no default interface, so failed to do resolve. (Note that there is no such issue in JB/KK, because JB/KK has different design for dns query mechanism and we also do some special handler for JB/KK)
See Also: → 992772
OS: Linux → Gonk (Firefox OS)
Hardware: x86 → ARM
Whiteboard: [CR 820235]
Whiteboard: [CR 820235] → [caf priority: p2][CR 820235]
triage: this is major issue and root cause was found

also ni to Eric: should we consider adding corresponding test cases, for the cases that given hostname is not IP.
blocking-b2g: 2.2? → 2.2+
Flags: needinfo?(echang)
Keep ni as a reminder for creating test case, but when testing we need proper env or we need to tweak the apn setting, will check with rd to get more details.
Per discussion with Bevis, the landing of bug 992772 should result in this bug being fixed correspondingly.
However, let me set dependency rather than duplicate for now. Once we verify bug 992772, we will know if we can close this safely.
Depends on: 92772
Depends on: 992772
No longer depends on: 92772
I have a idea about testing this issue but it requires to modify the gecko

1) Add a preference for custom mobile dns info
2) While the custom dns info is null, use the dns info provisioned by carrier
3) While the custom dns info is valid, use the custom one.
4) Host our own custom dns server.
5) To make this issue happen, we set the preference to our custom DNS server and
   assign a special domain name for MMS which can be only resolved by our custom server.
Would you take this bug?
I'll take this bug to follow up instead.
Assignee: nobody → btseng
Bevis, does the patch in apply on 2.2 codebase for CFA to test this out ?
Flags: needinfo?(btseng)
(In reply to bhavana bajaj [:bajaj] from comment #10)
> Bevis, does the patch in
> apply on 2.2 codebase for CFA to test this out ?

Bug 992772 is marked as 2.2+, so I expect it will be uplift to v2.2 branch.
Flags: needinfo?(btseng)
Quick update: Bug 992772 was marked as checkin-needed.
Now bug 992772 has approval-mozilla-b2g37+
bug 992772 is landed, close this bug.
Closed: 9 years ago
Resolution: --- → DUPLICATE
No longer blocks: CAF-v2.2-metabug
Flags: needinfo?(echang) → needinfo?(hcheng)
move to in-moztrap flag
Flags: needinfo?(hcheng) → in-moztrap?(hcheng)
Flags: in-moztrap?(hcheng) → in-moztrap?(gchang)
You need to log in before you can comment on or make changes to this bug.