Closed Bug 998244 Opened 6 years ago Closed 5 years ago

[ZTE][OPEN C_1.3]MMS cannot be sent in the network of Join operator

Categories

(Firefox OS Graveyard :: Vendcom, defect, major)

ARM
Gonk (Firefox OS)
defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1115486

People

(Reporter: zhang.ruili, Assigned: kchang, NeedInfo)

References

Details

(Whiteboard: [ETA=5/30])

Attachments

(11 files)

227.41 KB, text/x-log
Details
292.24 KB, application/x-zip-compressed
Details
630.70 KB, application/x-executable
Details
561.29 KB, application/x-zip-compressed
Details
24 bytes, application/octet-stream
Details
147.37 KB, application/x-7z-compressed
Details
74.78 KB, text/plain
Details
181.59 KB, application/octet-stream
Details
8.27 MB, application/x-7z-compressed
Details
8.43 MB, application/x-7z-compressed
Details
8.42 MB, application/x-7z-compressed
Details
Attached file logcat_main.log
User Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36

Steps to reproduce:

The Join operator mms profile is:
anp is 'joinmms'
mms proxy is 'joinproxy'
mms proxy port is '8080'
mmsc is 'http://joinmms'

Compose a mms and send.


Actual results:

It cannot be sent successfully.


Expected results:

Sending and receiving should be ok.
Please turn on ril debugging and attach the resulting log. Thanks !
Component: Gaia::SMS → RIL
Flags: needinfo?(zhang.ruili)
Attachment is the log with enabled mms.debugging.enabled. It seems parse proxy error.
Severity: normal → major
blocking-b2g: --- → 1.3?
Component: RIL → Gaia::SMS
OS: All → Gonk (Firefox OS)
Hardware: All → ARM
Component: Gaia::SMS → RIL
Flags: needinfo?(btseng)
(In reply to RuiLi from comment #2)
> Attachment is the log with enabled mms.debugging.enabled. It seems parse
> proxy error.

Hi RuiLi,

May I know what proxy parsed error means here?

From the log, it seems that MmsService register the proxy to |joinproxy| with port:8080 at line#1139 of the log:
04-17 09:46:39.247 I/Gecko   (  298): -@- MmsService: getProxyInfo: {"host":"joinproxy","port":8080,"type":"http","flags":1,"resolveFlags":0,"failoverTimeout":1800,"failoverProxy":null,"TRANSPARENT_PROXY_RESOLVES_HOST":1}

and the target url is http://joinmms for sending MMS at line#1137:
04-17 09:46:39.237 I/Gecko   (  298): -@- MmsService: sendRequest: register proxy filter to http://joinmms

The problem is that we got response status from remote side equal to 0 at line#1147:
04-17 09:46:39.417 I/Gecko   (  298): -@- MmsService: xhr done, but status = 0, statusText =
Flags: needinfo?(btseng)
It's just my guess. The error log 'MmsService: Fail to send' shows very soon, so I guess the network maybe not connected.
Flags: needinfo?(zhang.ruili)
No(In reply to RuiLi from comment #4)
> It's just my guess. The error log 'MmsService: Fail to send' shows very
> soon, so I guess the network maybe not connected.

No, the network is connected from MmsService's viewpoint at line#1135:
04-17 09:46:39.237 I/Gecko   (  298): -@- MmsService: Got the MMS network connected! Resend the buffered MMS requests: number: 1

Since this is QC RIL included Build according to the log,
We need QC's help to 
1. Clarify if the MMS data connection is correctly established.
2. Clarify if there is any problem to transmit the data.
Flags: needinfo?(anshulj)
In addition, I found 2 suspicious log printed but I can't find these logs in gecko 1.3:
04-17 09:46:39.007 D/DHCP    (  298): getaddrinfo failed: invalid address 
04-17 09:46:39.117 D/DHCP    (  298): getaddrinfo failed: invalid address 
Does that provide the hints that joinproxy and joinmms are failed to be resolved?
Phil, could you please reply to comment #5?
Flags: needinfo?(anshulj) → needinfo?(pgravel)
From the main logs, it seeems the MMS data calls seems up and available. Would have to look at the radio logs to validate that analysis.

However... the symptoms are very similar to bug995486 (near instant "xhr done, but status = 0, statusText = " error). I wonder if there's a generic issue with resolving hosts that are not accessible from a generic connection. Perhaps connections of the MMS type are not being added to the routing table properly?
Flags: needinfo?(pgravel)
Vance - Can you find out if this is a certification blocker or not?
Flags: needinfo?(vchen)
Yes, this is a cert blocker
Flags: needinfo?(vchen)
blocking-b2g: 1.3? → 1.3+
Whiteboard: [cert]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file logs.zip
I attached logs.zip with 'ril.debugging.enabled' and 'mms.debugging.enabled' enabled. Please check whether it is useful.
(In reply to pgravel from comment #8)
> From the main logs, it seeems the MMS data calls seems up and available.
> Would have to look at the radio logs to validate that analysis.
> 
> However... the symptoms are very similar to bug995486 (near instant "xhr
> done, but status = 0, statusText = " error). I wonder if there's a generic
> issue with resolving hosts that are not accessible from a generic
> connection. Perhaps connections of the MMS type are not being added to the
> routing table properly?

Hi Phil,RuiLi,

Before sending the MMS, I saw the following 2 errors from DHCP:
04-17 09:46:39.007 D/DHCP    (  298): getaddrinfo failed: invalid address 
04-17 09:46:39.117 D/DHCP    (  298): getaddrinfo failed: invalid address 
However, I didn't see any log tagged with "DHCP" in gecko's code base.
Is there any modification by QC or ZTE that printed this error?
This will be helpful to know what's going on when resolving the mmsc/mmsproxy.

Regards,
Bevis
Flags: needinfo?(zhang.ruili)
Flags: needinfo?(pgravel)
Assignee: nobody → btseng
I checked that 'getaddrinfo failed: invalid address' and 'failed to remove default route for rmnet1' are both in system/core/libnetutils/ifc_utils.c. Could you help us for this issue. It's a very crucial bug. Thank you.
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #12)
> (In reply to pgravel from comment #8)
> > From the main logs, it seeems the MMS data calls seems up and available.
> > Would have to look at the radio logs to validate that analysis.
> > 
> > However... the symptoms are very similar to bug995486 (near instant "xhr
> > done, but status = 0, statusText = " error). I wonder if there's a generic
> > issue with resolving hosts that are not accessible from a generic
> > connection. Perhaps connections of the MMS type are not being added to the
> > routing table properly?
> 
> Hi Phil,RuiLi,
> 
> Before sending the MMS, I saw the following 2 errors from DHCP:
> 04-17 09:46:39.007 D/DHCP    (  298): getaddrinfo failed: invalid address 
> 04-17 09:46:39.117 D/DHCP    (  298): getaddrinfo failed: invalid address 
> However, I didn't see any log tagged with "DHCP" in gecko's code base.
> Is there any modification by QC or ZTE that printed this error?
> This will be helpful to know what's going on when resolving the
> mmsc/mmsproxy.
> 
> Regards,
> Bevis
Flags: needinfo?(zhang.ruili)
(In reply to RuiLi from comment #13)
> I checked that 'getaddrinfo failed: invalid address' and 'failed to remove
> default route for rmnet1' are both in system/core/libnetutils/ifc_utils.c.
> Could you help us for this issue. It's a very crucial bug. Thank you.

Hi,

This looks not in gecko scope. 
I am afraid that I don't have too much knowledge here to help.
Assignee: btseng → nobody
Component: RIL → Vendcom
Hi RuiLi,

May I know if Wifi or Default Data Connection is ON during the test?
There is a known issue bug 992772 if WiFi is enabled when sending/receiving MMS with both mmsproxy/mmsc not configured in ip-addresses.
We don't have a short-term solution for this bug due to AOSP version and current Gecko design.
The workaround is to have the ip-address of MMSC/MMS Proxy in the APN settings instead in this case.
If MMS Proxy is needed, then we need ip-address of MMS Proxy to be configured in the default MMS APN Settings.
Otherwise, we need ip-address of MMSC to be configured.

Is it possible to know what happen if data/wifi is not enabled when sending MMS?

In addition, from the error log "getaddrinfo failed: invalid address" and the source code of ifc_utils.c:
    ret = getaddrinfo(dst, NULL, &hints, &addr_ai);

    if (ret != 0) {
        printerr("getaddrinfo failed: invalid address %s\n", dst);
        return -EINVAL;
    }
It seems that the resolved ip-address (dst) is empty.
Is it possible to 
1. enable DEBUG flag in NetworkManager.js[1]?
2. add more log in [2] to see what hostname to be resolve.
3. And check [3] to see the resolved ip-address.

The possible problem I guess is that the returned |ip-address| in [3] might be empty that cause 'getaddrinfo failed: invalid address' printed out while adding/removing HostRoutes.

[1] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e0de32a9d4ac/dom/system/gonk/NetworkManager.js#l94
[2] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e0de32a9d4ac/dom/system/gonk/NetworkManager.js#l585
[3] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e0de32a9d4ac/dom/system/gonk/NetworkManager.js#l588
Flags: needinfo?(zhang.ruili)
Wifi is disabled and Data connection is on while testing. We can retry in the case of Data connection off.
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #15)
> Hi RuiLi,
> 
> May I know if Wifi or Default Data Connection is ON during the test?
> There is a known issue bug 992772 if WiFi is enabled when sending/receiving
> MMS with both mmsproxy/mmsc not configured in ip-addresses.
> We don't have a short-term solution for this bug due to AOSP version and
> current Gecko design.
>
Flags: needinfo?(zhang.ruili)
mvines - We haven't heard back from pgravel yet to confirm if this is a QC problem. Can you followup here to determine if this is a QC problem?
Flags: needinfo?(mvines)
NI reporter for more debugging logs in comment 15:
--
Is it possible to 
1. enable DEBUG flag in NetworkManager.js[1]?
2. add more log in [2] to see what hostname to be resolve.
3. And check [3] to see the resolved ip-address.

The possible problem I guess is that the returned |ip-address| in [3] might be empty that cause 'getaddrinfo failed: invalid address' printed out while adding/removing HostRoutes.

[1] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e0de32a9d4ac/dom/system/gonk/NetworkManager.js#l94
[2] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e0de32a9d4ac/dom/system/gonk/NetworkManager.js#l585
[3] http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e0de32a9d4ac/dom/system/gonk/NetworkManager.js#l588
Flags: needinfo?(zhang.ruili)
Once I get the log, I'll attach it.
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #18)
> NI reporter for more debugging logs in comment 15:
> --
> Is it possible to 
> 1. enable DEBUG flag in NetworkManager.js[1]?
> 2. add more log in [2] to see what hostname to be resolve.
> 3. And check [3] to see the resolved ip-address.
> 
> The possible problem I guess is that the returned |ip-address| in [3] might
> be empty that cause 'getaddrinfo failed: invalid address' printed out while
> adding/removing HostRoutes.
> 
> [1]
> http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e0de32a9d4ac/dom/
> system/gonk/NetworkManager.js#l94
> [2]
> http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e0de32a9d4ac/dom/
> system/gonk/NetworkManager.js#l585
> [3]
> http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/e0de32a9d4ac/dom/
> system/gonk/NetworkManager.js#l588
Flags: needinfo?(zhang.ruili)
Flags: needinfo?(mvines) → needinfo?(pgravel)
For the time being does not appear to be a QCRIL problem - waiting to see the logs requested from comment #15, it will help track down the root cause.
Thanks for the continued investigation Bevis, your analysis has been quite valuable.
Flags: needinfo?(pgravel)
ni Ruili

Hi Ruili, per Comment#5, please do help  provide logs such that we can move forward this bug
Flags: needinfo?(zhang.ruili)
Attached file tcpdump
Upload tcpdump executive.

Step to capture tcpdump:
  1. Install attached tcpdump command into test device:
     $adb remount; adb push tcpdump system/bin/;adb shell chmod 777 /system/bin/tcpdump
  2. Start capturing tcpdump:
     $adb shell tcpdump -i any -p -s 0 -w /data/capture.pcap
  3. backup tcpdump result:
     $adb pull /data/capture.pcap .
When collecting adb logcat, 
please also help to collect the tcpdump with the binary attached in comment 22.

Thanks,
Bevis
Attached file ap_log.zip
I got the adb log and tcpdump log. I enabled all these 3 steps, but i didn't find the log info from Step 2 and 3.
Flags: needinfo?(zhang.ruili)
Attached file tcp.pcap
This is the tcpdump log, but no more information in it.
Hi Bevis, RuiLi has provided some log, could you take a look on it? thank you.
Flags: needinfo?(btseng)
We have met several MMS issues in different live networks recently,
After further investigation and review current implementation, 
there is some limitation in current design to support MMS under
some carriers if following condition is met:
1. If MMS Proxy is needed, then 
   - MMS Proxy must either be an ip-address in APN configuration.
   - Or, must to resolvable from public network.
2. If MMS Proxy is not needed, then 
   - MMSC server must either be an ip-address in APN configuration.
   - Or, must to resolvable from public network.
The reason has been explain in bug 992772.
In short, in current implementation, 
we are not possible to resolve hostname with specified network interface.
That also means that we might not able to 
set up the routing table of MMS Proxy/MMSC accordingly if the condition mentioned above is met.

To support resolving hostname with specified network interface is a big design change.

A short-term workaround for Join Operator we suggest is 
to fill the ip-address of the MMS Proxy instead of |joinproxy|.
(The pre-condition is that the ip-address of joinproxy will never be changed.)

NI to know if this short-term solution is workable due to the limitation in current design.
Component: Vendcom → RIL
Flags: needinfo?(zhang.ruili)
Flags: needinfo?(btseng)
Hi Vence,
  Can you please discuss with partner to see if comment 27 works for partner?
Flags: needinfo?(vchen)
Although there is no assignee in this bug, we are communicating with TAM. But taking this bug first for avoiding the confusion.
Assignee: nobody → kchang
Flags: in-moztrap-
Vance, any update. Can we close this bug?
Flags: needinfo?(vchen)
Whiteboard: [cert] → [cert][ETA=5/30]
Change to Vendcom.

Dear ZTE fellows, I believe Mozilla already provide some tips regarding how to send MMS successfully in joint network. I will De-nom 1.3+ here, please nominate again if you still have any problem

Thanks

Vance
blocking-b2g: 1.3+ → ---
Component: RIL → Vendcom
Whiteboard: [cert][ETA=5/30] → [ETA=5/30]
Hi Vance, 
we have config ip address for that, and waiting for our testing engineer to verity it. Due to our tester not in that country now, maybe feedback would delay for a few days. 
Thank you all.
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #31)
> Change to Vendcom.
> 
> Dear ZTE fellows, I believe Mozilla already provide some tips regarding how
> to send MMS successfully in joint network. I will De-nom 1.3+ here, please
> nominate again if you still have any problem
>
Flags: needinfo?(zhang.ruili)
Hi Vance,
I was RuiLi's colleague. Now we encountered the following problem.
With French free card, mmsc using IP mode,we still can not successfully send MMS.
mmsc specific configuration is as follows:

"15": [
    {"carrier":"Free","apn":"free","type":["default","supl"]},
    {"carrier":"Free MMS","apn":"mmsfree","mmsc":"http://212.27.40.225","type":["mms"]}
  ],
Flags: needinfo?(vchen)
Hi Kris -

Let's not bundle all issues together here. Could you submit another issue to Bugzilla for this cannot send MMS issue in France?

Thanks

Vance
Flags: needinfo?(vchen) → needinfo?(pan.lei6)
Attached file logs0624.7z
Please also have adb logcat with mms/ril enabled and the corresponding tcpdump for further analysis as well.

You can follow the steps and tools in the linked below for logcat/tcpdump:
https://github.com/bevis-tseng/Debug_Tools

Thanks.
Attached file logcat.txt
Attached file capture.pcap
Hi,
Another similar issue happens for operator "FREE".
Then we changed the mmsc to IP, do the following test.
Test 1:
Open C 1 send mms, Open C 1 receive, successfully

Test 2:
Open C 1 send mms, Open C2 receive, fail, Open C 2 can not received mms

Test 3:
Android Reference Phone Vec4G send mms, Open C receive, successfully

Test 4:
Open C send mms, Android Reference Phone Vec4G receive, fail, Vec4G can not received mms

The logs are attached, please check it.
For failed case, we can not receive the mms-notification-ind with short message.
As mentioned in comment 34, please have different bug to trace different symptoms.
Bug 1029453 seems to be the one for the MMS problem in Free.
Please move the attachment & discussion in that bug and have correct title/issue description about being not able to received MMS in 'Free' Operator instead.

Thanks!
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1115486
You need to log in before you can comment on or make changes to this bug.