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

Status: RESOLVED DUPLICATE of bug 1171283

(Firefox OS Graveyard :: RIL, defect)

Description

[Marcia Knous [:marcia]]

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

Comment 1

[Marcia Knous [:marcia]]

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.

Comment 2

[Steve Chung [:steveck]]

Looks like same issue in bug 1146393?

Comment 3

[Julien Wajsberg [:julienw]]

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.

Comment 4

[David Flanagan [:djf]]

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.

Comment 5

[Julien Wajsberg [:julienw]]

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.

Comment 6

[Pi Wei Cheng [:piwei] (inactive)]

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

Comment 7

[Julien Wajsberg [:julienw]]

Great !

Now we can summon Bevis to take a look at the issue ;)

Comment 8

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

 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!

Comment 9

[Marcia Knous [:marcia]]

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

Comment 10

[Marcia Knous [:marcia]]

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

Comment 11

[Marcia Knous [:marcia]]

Attachment: capture.pcap

tcpdump logging as requested in bug. Hopefully I did it correctly.

Comment 12

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

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

Comment 13

[Marcia Knous [:marcia]]

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.

Comment 14

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

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

Comment 15

[Marcia Knous [:marcia]]

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

Comment 16

[Marcia Knous [:marcia]]

Attachment: capture.pcap - Flame with AT&T SIM

Logging captured on Flame device/latest nightly with AT&T SIM.

Comment 17

[Marcia Knous [:marcia]]

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)

Comment 18

[Doug Sherk (:drs) (inactive)]

David, could you help us figure out the path forward for this?

Comment 19

[David Flanagan [:djf]]

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.

Comment 20

[Marcia Knous [:marcia]]

Attachment: adb logcat -v threadtime - Flame TMobile

Comment 21

[Marcia Knous [:marcia]]

Attachment: adb logcat -v threadtime -b radio - Flame TMobile

Comment 22

[Marcia Knous [:marcia]]

Attachment: capture.pcap - Flame with Tmobile

Comment 23

[Marcia Knous [:marcia]]

Attachment: adb logcat -v threadtime -b radio - Flame device/AT&T

Comment 24

[Marcia Knous [:marcia]]

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

Comment 25

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

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!

Comment 26

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

(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

Comment 27

[David Flanagan [:djf]]

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.

Comment 28

[David Flanagan [:djf]]

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?

Comment 29

[Pi Wei Cheng [:piwei] (inactive)]

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.

Comment 30

[Marcia Knous [:marcia]]

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.

Comment 31

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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

Comment 32

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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.

Comment 33

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

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!

Comment 34

[Marcia Knous [:marcia]]

Attachment: Logcat with adb shell ifconfig rmnet0 mtu 1440

Comment 35

[Marcia Knous [:marcia]]

Attachment: capture.pcap

Requested logging from Comment 25.

Comment 36

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

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!

Comment 37

[Pi Wei Cheng [:piwei] (inactive)]

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

Comment 38

[Marcia Knous [:marcia]]

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

Comment 39

[Marcia Knous [:marcia]]

Attachment: logcat.txt

New logcat - Bevis please let me know if this captured what you requested.

Comment 40

[Marcia Knous [:marcia]]

Attachment: capture.pcap

Trying the log capture again.

Comment 41

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

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.