Closed
Bug 998244
Opened 10 years ago
Closed 9 years ago
[ZTE][OPEN C_1.3]MMS cannot be sent in the network of Join operator
Categories
(Firefox OS Graveyard :: Vendcom, defect)
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 |
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.
Comment 1•10 years ago
|
||
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
Updated•10 years ago
|
Component: Gaia::SMS → RIL
Updated•10 years ago
|
Flags: needinfo?(btseng)
Comment 3•10 years ago
|
||
(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)
Comment 5•10 years ago
|
||
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)
Comment 6•10 years ago
|
||
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)
Comment 9•10 years ago
|
||
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)
Updated•10 years ago
|
blocking-b2g: 1.3? → 1.3+
Whiteboard: [cert]
Updated•10 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reporter | ||
Comment 11•10 years ago
|
||
I attached logs.zip with 'ril.debugging.enabled' and 'mms.debugging.enabled' enabled. Please check whether it is useful.
Comment 12•10 years ago
|
||
(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)
Updated•10 years ago
|
Assignee: nobody → btseng
Reporter | ||
Comment 13•10 years ago
|
||
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)
Comment 14•10 years ago
|
||
(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
Comment 15•10 years ago
|
||
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)
Reporter | ||
Comment 16•10 years ago
|
||
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)
Comment 17•10 years ago
|
||
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)
Comment 18•10 years ago
|
||
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)
Reporter | ||
Comment 19•10 years ago
|
||
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)
Updated•10 years ago
|
Flags: needinfo?(mvines) → needinfo?(pgravel)
Comment 20•10 years ago
|
||
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)
Comment 22•10 years ago
|
||
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 .
Comment 23•10 years ago
|
||
When collecting adb logcat, please also help to collect the tcpdump with the binary attached in comment 22. Thanks, Bevis
Reporter | ||
Comment 24•10 years ago
|
||
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)
Reporter | ||
Comment 25•10 years ago
|
||
This is the tcpdump log, but no more information in it.
Comment 26•10 years ago
|
||
Hi Bevis, RuiLi has provided some log, could you take a look on it? thank you.
Flags: needinfo?(btseng)
Comment 27•10 years ago
|
||
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)
Updated•10 years ago
|
Flags: needinfo?(btseng)
Assignee | ||
Comment 28•10 years ago
|
||
Hi Vence, Can you please discuss with partner to see if comment 27 works for partner?
Flags: needinfo?(vchen)
Assignee | ||
Comment 29•10 years ago
|
||
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
Updated•10 years ago
|
Flags: in-moztrap-
Assignee | ||
Comment 30•10 years ago
|
||
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
Updated•10 years ago
|
Whiteboard: [cert][ETA=5/30] → [ETA=5/30]
Reporter | ||
Comment 32•10 years ago
|
||
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)
Comment 33•10 years ago
|
||
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)
Comment 35•10 years ago
|
||
Comment 36•10 years ago
|
||
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.
Comment 37•10 years ago
|
||
Comment 38•10 years ago
|
||
Comment 39•10 years ago
|
||
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.
Comment 40•10 years ago
|
||
Comment 41•10 years ago
|
||
Comment 42•10 years ago
|
||
Comment 43•10 years ago
|
||
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!
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•