[Aries] Not able to send MMS picture from Gallery App

RESOLVED DUPLICATE of bug 1171283

Status

RESOLVED DUPLICATE of bug 1171283
3 years ago
3 years ago

People

(Reporter: marcia, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:2.5+)

Details

(Whiteboard: [spark])

Attachments

(13 attachments, 2 obsolete attachments)

253.51 KB, text/plain
Details
487.03 KB, text/plain
Details
1.15 MB, image/jpeg
Details
72.17 KB, text/plain
Details
120.00 KB, application/octet-stream
Details
401.03 KB, text/plain
Details
64.00 KB, application/octet-stream
Details
338.24 KB, text/plain
Details
21.09 KB, text/plain
Details
148.00 KB, application/octet-stream
Details
8.68 KB, text/plain
Details
316.82 KB, text/plain
Details
28.00 KB, application/octet-stream
Details
Created attachment 8612618 [details]
Logcat of issue

[Blocking Requested - why for this release]: Common functionality that needs to work.

Gaia-Rev        18f7c340f970991a10c288310bbfd4d105a1430c
Gecko-Rev       b7aed25b94251ea192021885323f15e87fc39321
Build-ID        20150528210322
Version         41.0a1
Device-Name     aries
FW-Release      4.4.2
FW-Incremental  eng.worker.20150528.204812
FW-Date         Thu May 28 20:48:20 UTC 2015
Bootloader      s1

STR:
1. Select a picture from Gallery that has been taken previously by the Z3 camera
2. Create an MMS message and attach the picture to the message
3. Press send

Actual: It never sends, and just shows "sending"

This error shows in Logcat: E/Gallery ( 5687): Content JS ERROR: while resizing image: Failed to decode image in cropResizeRotate; image may be corrupt or too large: IndexSizeError: Index or size is negative or greater than the allowed amount 

Tested with latest nightly on the Flame and this operation (sending MMS from a gallery pic) seems to work fine.
Two additional data points:

I tried this operation in the Email app as well, and the same pictures I was trying to send via MMS generated an error message that the file was too large when trying to attach them in an email.

I have a few images on the device that were not taken by the Z3 camera in the gallery, and they also fail to be sent by MMS but worked when I attached them to an email.
Flags: needinfo?(drs)
Flags: needinfo?(dflanagan)
Looks like same issue in bug 1146393?
I don't think it's the same issue as this one is clearly in Gallery (I think we get a wrong blob here). I'm sure David will know better though.
Component: Gaia::SMS → Gaia::Gallery
I don't get it. Bug 1169055 shows that you can attach a photo to an MMS message, but that it comes out sideways. This bug shows an error message that is very helpful for diagnosing bug 1169055: the rotation isn't happening because the image is too large.

But if the image is displayed by the SMS app and still can't be sent, then I think that the issue is that the SMS app must be failing to resize the image.  (Probably for the same reason).

It could be that both bug 1169055 and this bug need to fix our image resizing code to deal with the giant images from the Aries camera.

But the specific bug described here is that the SMS app displays "sending" forever and never sends the message. It should succeed or fail, and not just try forever, so I think there is an SMS issue here.

Switching back to SMS. Julien: am I just misunderstanding something here? If you can convince me that this is a gallery bug I'm happy to take it.

Note however that my Aries device has not arrived yet, and I'm working on 2.2+ bugs right now, so I won't be able to get to Spark+ bugs until next week sometime.
Component: Gaia::Gallery → Gaia::SMS
Flags: needinfo?(dflanagan) → needinfo?(felash)
I see also this in the log, not sure it's related:

W/Gallery ( 5209): Content JS WARN: MediaDB: error parsing metadata for /sdcard1/._2015-Porsche-Macan-prototype-front-three-quarter-motion-796x528.jpg : createThumbnailAndPreview: Image failed to load 
W/Gallery ( 5209):     at metadataError (app://gallery.gaiamobile.org/gaia_build_defer_index.js:418:27)

Also not that the error:

E/Gallery ( 5687): Content JS ERROR: while resizing image: Failed to decode image in cropResizeRotate; image may be corrupt or too large: IndexSizeError: Index or size is negative or greater than the allowed amount 
E/Gallery ( 5687):     at end/< (app://gallery.gaiamobile.org/js/pick.js:300:26)
E/Gallery ( 5687):     at gotImage (app://gallery.gaiamobile.org/shared/js/media/crop_resize_rotate.js:519:1)

appears 3 times.

There is no message at all otherwise. It would be useful to have the RIL+MMS logs as explained in https://github.com/bevis-tseng/Debug_Tools.
Flags: needinfo?(felash)
Keywords: qawanted
Flags: needinfo?(drs)
Created attachment 8613139 [details]
logcat with RIL + MMS + Network debugs enabled

Attaching the logcat with requested preferences enabled.

Tested on:
Device: Xperia Z3 Compact (B2G) 3.0
Build ID: 20150528210322
Gaia: 18f7c340f970991a10c288310bbfd4d105a1430c
Gecko: b7aed25b94251ea192021885323f15e87fc39321
Version: 41.0a1 (3.0)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Great !

Now we can summon Bevis to take a look at the issue ;)
Flags: needinfo?(btseng)
 15:24:27.552  3013  3013 I Gecko   : -@- MmsService: sendRequest: register proxy filter to http://mms.msg.eng.t-mobile.com/mms/wapenc

From the log, I saw a request was sent to the MMSC.
However, there is not further response which keeps the request waiting after 27 seconds.
I am wonder if the sending is not finished yet if the picture is too large due to the problem to resize the attached picture.

Since this is not reproducible on Flame with latest nightly, I need reporter's help to:
1. Attach the test picture used in Z3C to this bug for us to see if we can reproduce this locally.
2. Send this Z3C-captured picture by Flame to see if there is any difference compared to Z3C.
3. Capture both 'logcat' and 'tcpdump' with the instruction in https://github.com/bevis-tseng/Debug_Tools.
   (Please wait longer to see if the picture will be sent eventually.)

Thanks!
Flags: needinfo?(btseng) → needinfo?(mozillamarcia.knous)
Created attachment 8613525 [details]
Sample Picture from Z3 device

As requested, here is a sample image that was taken using the Z3 and which I cannot send using MMS.

I was able to copy this same attached image to the Flame device, and using a recent nightly, send it successfully via MMS.

Will work on the logs next. Here is the version currently running on the Z3:

Gaia-Rev        18f7c340f970991a10c288310bbfd4d105a1430c
Gecko-Rev       b7aed25b94251ea192021885323f15e87fc39321
Build-ID        20150528210322
Version         41.0a1
Device-Name     aries
FW-Release      4.4.2
FW-Incremental  eng.worker.20150528.204812
FW-Date         Thu May 28 20:48:20 UTC 2015
Bootloader      s1
Flags: needinfo?(mozillamarcia.knous)
Created attachment 8613592 [details]
adb logcat -v threadtime -b radio

I waited quite a bit of time for the image to send, but it never did. Here is the logcat with the radio bit enabled.
Created attachment 8613601 [details]
capture.pcap

tcpdump logging as requested in bug. Hopefully I did it correctly.
From the tcpdump, I saw lots of error messages from ICMPv6 protocol said "Packet Too Big". [1]

I wonder if we have to set the MTU per network interface and I also like to know what's MTU configuration in flame.

Hi Marcia,

Would you please kindly help to collect both main/radio logcat and tcpdump from flame with the same picture to be sent in the same network for further comparison?

Thanks!

[1] https://tools.ietf.org/html/rfc4443#section-3.2
Component: Gaia::SMS → RIL
Flags: needinfo?(mozillamarcia.knous)
Bevis: I can provide what you want in Comment 12 from Flame, but the Flame device I have is on AT&T network with Standard SIM, and the Z3 is on TMobile with nano SIM. Does the carrier I am using matter in this instance? I can try using a SIM card adapter kit if so.
Flags: needinfo?(mozillamarcia.knous) → needinfo?(btseng)
(In reply to Marcia Knous [:marcia - use ni] from comment #13)
> Bevis: I can provide what you want in Comment 12 from Flame, but the Flame
> device I have is on AT&T network with Standard SIM, and the Z3 is on TMobile
> with nano SIM. Does the carrier I am using matter in this instance? I can
> try using a SIM card adapter kit if so.

Hi Marcia,

Thanks for asking.

Yes, I think the carrier you use does matter according to the error message we found in comment 12 which is a network-specific error.
Hence, I think we have to do more comparison between Z3 & Flame on T-Mobile & AT&T with main/radio logcats & tcpdumps from these 2 devices under these 2 networks.

In addition, if both Z3 & Flame are failed on T-Mobile network, is it possible to have main/radio logcats & tcpdump of Z3 in Android build if MMS can be sent successfully in Z3 Android for further comparison?

Thanks!
Flags: needinfo?(btseng) → needinfo?(mozillamarcia.knous)
Created attachment 8614496 [details]
adb logcat -v threadtime - Flame device/AT&T

Attaching logcat from Flame device running latest nightly with AT&T SIM card. The MMS was sent successfully from this device.
Flags: needinfo?(mozillamarcia.knous)
Created attachment 8614497 [details]
capture.pcap - Flame with AT&T SIM

Logging captured on Flame device/latest nightly with AT&T SIM.
Things remaining from Comment 12:

*Sending MMS from Flame on TMobile network (will try SIM adapter tomorrow in office)
*Sending MMS from Z3 on AT&T (need a NanoSIM from AT&T or will have to try to cut a full size SIM and hope for the best)
David, could you help us figure out the path forward for this?
blocking-b2g: spark? → spark+
Flags: needinfo?(dflanagan)
Doug: happy to help on this, if I can, but I'm still waiting for my device to arrive.  Since it wasn't sent with the signature waiver I requested, it may be a couple of days yet before fedex and I are in the same place at the same time.

Then, once the device arrives, I won't have a nano sim card for it, so if the bug actually requires me to be sending an MMS message to reproduce, that will probably be a pretty big obstacle.

Maybe, though, once I can work on 1069055, that might help with this bug, too.

Leaving the needinfo set so I don't forget about this, but it is not clear when or whether I'll be able to help.
Created attachment 8614881 [details]
adb logcat -v threadtime - Flame TMobile
Created attachment 8614882 [details]
adb logcat -v threadtime -b radio - Flame TMobile
Created attachment 8614887 [details]
capture.pcap - Flame with Tmobile
(Reporter)

Updated

3 years ago
Attachment #8614496 - Attachment description: adb logcat -v threadtime -b radio - Flame device/AT&T → adb logcat -v threadtime - Flame device/AT&T
Created attachment 8614889 [details]
adb logcat -v threadtime -b radio - Flame device/AT&T
(In reply to Marcia Knous [:marcia - use ni] from comment #17)
> Things remaining from Comment 12:
> 
> *Sending MMS from Flame on TMobile network (will try SIM adapter tomorrow in
> office)
> *Sending MMS from Z3 on AT&T (need a NanoSIM from AT&T or will have to try
> to cut a full size SIM and hope for the best)

I think all logs are there now, except for MMS from Z3 on AT&T. From what I can see, sending the MMS image with the TMobile/Flame combination worked, except I think one time sending the image might have failed. But it didn't fail continuously like it does on the Z3.
Hi Marcia,

Thanks for providing these logs.
After investigation, we found that, in flame, IPv4 is used and there is no MTU issue in IPv4 network, because routers will help on this.
However, in IPv6, this has to be controlled by the sender and this is not supported in our implementation yet.

To double confirm the root cause, we'd like to ask your help to manually configure the MTU for Z3 before sending MMS to see if the MMS message can be sent properly:
1. Enable Data Connection and make sure you can connect to the internet with browser. (the default connection and mms share the same APN settings in T-Mobile)
2. Set MTU manually by "adb shell ifconfig rmnet0 mtu 1440".
3. Send a MMS message.

Please also have the main logcat and tcpdump started from device boot-up for further analysis.

Thanks!
Flags: needinfo?(mozillamarcia.knous)
(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #25)
> 2. Set MTU manually by "adb shell ifconfig rmnet0 mtu 1440".

Note: The preferred MTU for T-Mobile is 1440 according to its apn setting in [1].

[1] https://github.com/mozilla-b2g/gaia/blob/master/shared/resources/apn.json#L1303
This might actually be the same bug as 1169680. The regression caused by bug 1154974 is causing code that resizes images to fail. We see this in comment 5, for example. So we know that the gallery app can send an image that is too big to the sms app. I don't recall what code the SMS app is using, but I think there is a chance that the sms app is not correctly resizing the big image it gets from gallery and sending is failing because we're trying to send something that is much too large for an MMS message.

Before we go any further into debugging the RIL, let's make sure that this is not just another regression from bug 1154974.  Setting QA wanted to test this with that patch backed out, or to test and see if this issue began when that patch landed.
Flags: needinfo?(dflanagan)
Keywords: qawanted
I've tried investigating _resizeImageBlobWithRatio() in apps/sms/views/shared/js/utils.js and it looks like it is correctly resizing the blob. I'm testing this on a Flame, though, and can't reproduce the bug, so this doesn't mean that there isn't some kind of error there.

Marcia: when you attach an image to an MMS message, the image has a small overlay saying how many kb the image is.  What size do you see when this bug occurs?
For the qawanted request, we don't have a way of getting builds from a specific date for the aries on Task Cluster.

The earliest build I was able to get from this link,
https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-central.revision.linux/gecko.v1.mozilla-central.revision.linux

is a build from 5/24, which bug 1154974 has already landed.

NI Naoki to get an Aries build from 5/19 or 5/20 so we can test a build before bug 1154974 landed.
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Bug 1171283 suggests that there is an overall problem with sending any MMS messages on the Z3 using TMobile. I have primarily been using a TMobile card in the Z3. Today I got an AT&T nano SIM and I am able to send images taken with the Z3 with no issues (same build)

In answer to Comment 28, it looks as if the size of the image is 79.4 KB on the TMobile device.
Flags: needinfo?(mozillamarcia.knous)
There's no easy way of getting a build other than using treeherder until bug 1133074  lands.
Ex:
1. go to the right repo on treeherder
2. find the date of a build job that has an Aries (B/Be) : https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=b9424d63fe35
3. take the gecko revision b9424d63fe35 and then go to the taskcuster
4. go to the right artifact index of task cluster : https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-central.revision.linux/gecko.v1.mozilla-central.revision.linux
5. search for the revision, click on the revision, click on the device, click on tasks, click on either debug or opt 
Note : For the device, I think we only had eng builds at this point in time.  aries-eng
6. this should lead you to : https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-central.revision.linux.b9424d63fe3525ae297a7faf3b063e483bbd4108.aries-eng/gecko.v1.mozilla-central.revision.linux.b9424d63fe3525ae297a7faf3b063e483bbd4108.aries-eng.opt
Flags: needinfo?(nhirata.bugzilla) → needinfo?(pcheng)
James Lal had told me a better way of taking a look at the rev and then figuring out which build is right before the check-in.  For inbound there should be builds for aries.

I tried searching the the checkins, it didn't quite work.  I had to look at the push log ( https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml ) for the checkin and then find the check in right before that.

I then went to : https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-inbound.revision.linux/gecko.v1.mozilla-inbound.revision.linux and search for that check in:
https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-inbound.revision.linux.1f6a0d22592701d5bc23621082ff9a0f8fde9ed4.aries-eng/gecko.v1.mozilla-inbound.revision.linux.1f6a0d22592701d5bc23621082ff9a0f8fde9ed4.aries-eng.opt

Please test with that build.  This is the checkin right before the patch in question landed.
I'm still waiting for the result of the MTU configuration problem in T-Mobile network mentioned in comment 25.

Hence, set the NI again to the reporter.

Thanks!
Flags: needinfo?(mozillamarcia.knous)
Created attachment 8616013 [details]
Logcat with adb shell ifconfig rmnet0 mtu 1440
Flags: needinfo?(mozillamarcia.knous)
Created attachment 8616018 [details]
capture.pcap

Requested logging from Comment 25.
Hi Marcia,

After checking the log and tcpdump you attached in comment 34 and comment 35, I found that the MMS/Network related debug flags were not enabled and the tcpdump was captured incomplete. :(

May I have your help capture the logcat/tcpdump by the instruction in the link below again with the test steps in comment 25?
https://github.com/bevis-tseng/Debug_Tools

Thanks!
Flags: needinfo?(mozillamarcia.knous)
Thank you, Naoki.

Tested with the build provided at comment 32 and issue does reproduce. Therefore bug 1154974 could not have been the cause of this issue.

Device: Xperia Z3 Compact (B2G) 3.0
BuildID: 20150521171615
Gaia: 108278984be8409d648d270bfc4758b84bc51bc4
Gecko: 1f6a0d225927
Version: 41.0a1 (3.0 Master)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pcheng) → needinfo?(ktucker)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #36)
> Hi Marcia,
> 
> After checking the log and tcpdump you attached in comment 34 and comment
> 35, I found that the MMS/Network related debug flags were not enabled and
> the tcpdump was captured incomplete. :(
> 
> May I have your help capture the logcat/tcpdump by the instruction in the
> link below again with the test steps in comment 25?
> https://github.com/bevis-tseng/Debug_Tools
> 
> Thanks!

yes, sorry about that - I did run that command - will try again and obsolete those attachments.
Created attachment 8616262 [details]
logcat.txt

New logcat - Bevis please let me know if this captured what you requested.
Attachment #8616013 - Attachment is obsolete: true
Flags: needinfo?(mozillamarcia.knous)
Created attachment 8616269 [details]
capture.pcap

Trying the log capture again.
Attachment #8616018 - Attachment is obsolete: true
From comment 25 and comment 30, this issue is more likely to be related to the network configuration in T-Mobile network.

Since bug 1171283 has been filed as a more generic MMS sending problem of Z3C in T-Mobile,
I'd like to set this bug as duplicated to bug 1171283.

In addition, it seems that manually change the MTU to 1440 after data connection established is not working.
We need to figure out a way to see how to configure the MTU correctly to prevent the "Packet too Big Message" complaint from T-Mobile Network when sending MMS.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1171283
blocking-b2g: spark+ → 2.5+
You need to log in before you can comment on or make changes to this bug.