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)
QAWanted to see if it can be reproduced on Nexus 5 (L based).
Works fine on these 2. - NEXUS-5-L 5.1 master local build - NEXUS-5-L 5.0 v2.2 PVT rm 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 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
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+
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
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.
Edgar, Would you take this bug?
I'll take this bug to follow up instead.
Assignee: nobody → btseng
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 ?
(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.
Quick update: Bug 992772 was marked as checkin-needed.
Now bug 992772 has approval-mozilla-b2g37+
bug 992772 is landed, close this bug.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 992772
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.