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

Status: RESOLVED DUPLICATE of bug 992772

(Firefox OS Graveyard :: RIL, defect)

Description

[pgravel]

Attachment: 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 '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

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

QAWanted to see if it can be reproduced on Nexus 5 (L based).

Comment 2

[Eric Chang [:ericcc] [:echang]]

Works fine on these 2.
- NEXUS-5-L 5.1 master local build
- NEXUS-5-L 5.0 v2.2 PVT

rm qawanted

Comment 3

[Edgar Chen [:edgar]]

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)

Comment 4

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

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.

Comment 5

[Eric Chang [:ericcc] [: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.

Comment 6

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

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.

Comment 7

[Henry Chang [:hchang]]

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

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

Edgar,
Would you take this bug?

Comment 9

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

I'll take this bug to follow up instead.

Comment 10

[bhavana bajaj [:bajaj]]

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 ?

Comment 11

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

(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.

Comment 12

[Kai-Chih Hu [:khu]]

Quick update: Bug 992772 was marked as checkin-needed.

Comment 13

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

Now bug 992772 has approval-mozilla-b2g37+

Comment 14

[Ken Chang[:kenkai]]

bug 992772 is landed, close this bug.

Comment 15

[Hermes Cheng (inactive after July 27, 2015)]

move to in-moztrap flag