Closed
Bug 1152568
Opened 10 years ago
Closed 10 years ago
MMS Proxy routing problem in L when only MMS data call up
Categories
(Firefox OS Graveyard :: RIL, defect)
Tracking
(blocking-b2g:2.2+)
RESOLVED
DUPLICATE
of bug 992772
blocking-b2g | 2.2+ |
People
(Reporter: pgravel, Assigned: bevis)
References
Details
(Whiteboard: [caf priority: p2][CR 820235])
Attachments
(1 file)
20.98 KB,
text/x-log
|
Details |
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 'proxy.mobile.att.net', 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)
Comment 1•10 years ago
|
||
QAWanted to see if it can be reproduced on Nexus 5 (L based).
Keywords: qawanted
Comment 2•10 years ago
|
||
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
Comment 3•10 years ago
|
||
Routing looks good:
> 9789:04-08 15:19:54.342 260 2375 D NetworkUtils: Receiving "0 network route legacy 0 add 100 rmnet_data0 172.26.38.1/32 10.150.236.129" 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 172.26.38.2/32 10.150.236.129" 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
Updated•10 years ago
|
OS: Linux → Gonk (Firefox OS)
Hardware: x86 → ARM
Updated•10 years ago
|
Whiteboard: [CR 820235]
Updated•10 years ago
|
Whiteboard: [CR 820235] → [caf priority: p2][CR 820235]
Comment 4•10 years ago
|
||
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)
Comment 5•10 years ago
|
||
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.
Comment 6•10 years ago
|
||
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
Comment 7•10 years ago
|
||
I have a idea about testing this issue but it requires to modify the gecko code: 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.
Comment 8•10 years ago
|
||
Edgar, Would you take this bug?
Comment 10•10 years ago
|
||
Bevis, does the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=992772 apply on 2.2 codebase for CFA to test this out ?
Flags: needinfo?(btseng)
Assignee | ||
Comment 11•10 years ago
|
||
(In reply to bhavana bajaj [:bajaj] from comment #10) > Bevis, does the patch in https://bugzilla.mozilla.org/show_bug.cgi?id=992772 > 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)
Comment 12•10 years ago
|
||
Quick update: Bug 992772 was marked as checkin-needed.
Comment 13•10 years ago
|
||
Now bug 992772 has approval-mozilla-b2g37+
Comment 14•10 years ago
|
||
bug 992772 is landed, close this bug.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Updated•10 years ago
|
No longer blocks: CAF-v2.2-metabug
Updated•9 years ago
|
Flags: needinfo?(echang) → needinfo?(hcheng)
Updated•9 years ago
|
Flags: in-moztrap?(hcheng) → in-moztrap?(gchang)
You need to log in
before you can comment on or make changes to this bug.
Description
•