1039185 - [dolphin][mms] dolphin receives multiple read reports for one MMS when sending MMS to itself with some specific operator

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Peipei Cheng (needinfo if you need my action)]

Attachment: 7715FFOS_MMS_Multipleread report.zip

This issue was only reproduced in India. And the operator they were using is Airtel. Attached is slog.

Steps to reproduce
-----------------------------------------------------------------------------
0. Set SIM1 as data SIM
   Turn on Delivery report
   Turn off Read report
2. Send a MMS from SIM1 to SIM1, MMS was sent and received successfully
   --> Wait for a while, device received the read report
4. download the read report
   --> after the successful download of read report, another read report was received again.
   Repeat 4 and 5, the process keeps on going and going

There are two bugs mentioned above.
[1] When "Read report" was turned off, there should be no read report.
[2] Read a "read report" should not trigger another "read report"


But we could not reproduce this using China Mobile and China Unicom.
-------------------------------------------------------------------------------
1. Turn on read report:
   read report was received after a while (several minutes, it should be related to operator network). And the read report is a SMS.
2. Turn off read report:
   I didn't see any read report within 30 minutes.

Comment 1

[Lina.Guo]

  Because we cannot reproduce this issue here,and there are several related issues in sprd bugzilla.
  
  So please help check it,thanks a lot.

Comment 2

[Peipei Cheng (needinfo if you need my action)]

Shawn, do you mind to take a look at the log? We could not reproduce this locally. So it should be operator specific problem.

Comment 3

[Julien Wajsberg [:julienw]]

Redirecting my request to Bevis.

Comment 4

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

I can not see any Mms related logs in the attachment.

Is it possible to get both adb logcat with Mms enabled & tcpdump for further analysis by the steps of the following link:
https://github.com/bevis-tseng/Debug_Tools

Thanks!

Comment 5

[Peipei Cheng (needinfo if you need my action)]

lina, could you please ask Indian QA to help collect correct logs?

Comment 6

[Lina.Guo]

 Yes. But they have left the field test sites,I will try my best to contact them.

Comment 7

[Kun Tang]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #4)
> I can not see any Mms related logs in the attachment.
> 
> Is it possible to get both adb logcat with Mms enabled & tcpdump for further
> analysis by the steps of the following link:
> https://github.com/bevis-tseng/Debug_Tools
> 
> Thanks!

Hi Bevis Tseng,

    I want to confirm some problems of Debug_Tools.
    1）If the Debug_Tools can be used on branch V1.4?
    2）QA maybe us windows os，can enable_debug_flags.sh be run on windows os？
    3) Last but not the least，how to capture logs and tcpdump at the same time？ Please shared detailed steps if they are obtained at the same time.

Comment 8

[Lina.Guo]

Attachment: 7730ffos_mms_multipleread.log

This is a log from India QA,I hope it can give some help.

Comment 9

[Lina.Guo]

Hi peipei:

   please focus on [sprd324384] comment16,it's the log contains a video.Because it's too large,I couldn't add it as an attachment.

Comment 10

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

(In reply to Kun Tang from comment #7)
> (In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #4)
> > I can not see any Mms related logs in the attachment.
> > 
> > Is it possible to get both adb logcat with Mms enabled & tcpdump for further
> > analysis by the steps of the following link:
> > https://github.com/bevis-tseng/Debug_Tools
> > 
> > Thanks!
> 
> Hi Bevis Tseng,
> 
>     I want to confirm some problems of Debug_Tools.
>     1）If the Debug_Tools can be used on branch V1.4?
Yes, this can be applied for v1.4 as well.
For adb logcat, besides the |main log| by "adb logcat -v threadtime > logcat.txt", we also need the corresponding| radio log| to see the what's the SMS PDU from the modem.
You can get radio log by "adb logcat -v threadtime -b radio > logcat_radio.txt"
>     2）QA maybe use windows os，can enable_debug_flags.sh be run on windows os？
You can install cygwin to have unix console in windows environment.
>     3) Last but not the least，how to capture logs and tcpdump at the same
> time？ Please shared detailed steps if they are obtained at the same time.
You can open multiple consoles at the same time to capture whatever logs you want.

Besides log capturing, I'd like to ni you for the following question:
Can test double confirm the message is a normal incoming MMS or a MMS read report?
 According to OMA 6.7.2 PDU Read Report in [1], the most import fields in read report are:
 - Message-ID, From to identify the receiver of the sent MMS.
 - X-Mms-Read-Status to tell sender the read status of of the sent MMS for the specific receiver.
 Besides, if user receive a read report, there will be a sticker next to the sent MMS to indicate that the message is read instead.

If it's a incoming MMS, then we should identify if it's still an issue.

[1] http://technical.openmobilealliance.org/Technical/release_program/docs/MMS/V1_3-20110913-A/OMA-TS-MMS_ENC-V1_3-20110913-A.pdf

Comment 11

[Kun Tang]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #10)
> (In reply to Kun Tang from comment #7)
> > (In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #4)
> > > I can not see any Mms related logs in the attachment.
> > > 
> > > Is it possible to get both adb logcat with Mms enabled & tcpdump for further
> > > analysis by the steps of the following link:
> > > https://github.com/bevis-tseng/Debug_Tools
> > > 
> > > Thanks!
> > 
> > Hi Bevis Tseng,
> > 
> >     I want to confirm some problems of Debug_Tools.
> >     1）If the Debug_Tools can be used on branch V1.4?
> Yes, this can be applied for v1.4 as well.
> For adb logcat, besides the |main log| by "adb logcat -v threadtime >
> logcat.txt", we also need the corresponding| radio log| to see the what's
> the SMS PDU from the modem.
> You can get radio log by "adb logcat -v threadtime -b radio >
> logcat_radio.txt"
> >     2）QA maybe use windows os，can enable_debug_flags.sh be run on windows os？
> You can install cygwin to have unix console in windows environment.
> >     3) Last but not the least，how to capture logs and tcpdump at the same
> > time？ Please shared detailed steps if they are obtained at the same time.
> You can open multiple consoles at the same time to capture whatever logs you
> want.
> 
> Besides log capturing, I'd like to ni you for the following question:
> Can test double confirm the message is a normal incoming MMS or a MMS read
> report?
>  According to OMA 6.7.2 PDU Read Report in [1], the most import fields in
> read report are:
>  - Message-ID, From to identify the receiver of the sent MMS.
>  - X-Mms-Read-Status to tell sender the read status of of the sent MMS for
> the specific receiver.
>  Besides, if user receive a read report, there will be a sticker next to the
> sent MMS to indicate that the message is read instead.
> 
> If it's a incoming MMS, then we should identify if it's still an issue.
> 
> [1]
> http://technical.openmobilealliance.org/Technical/release_program/docs/MMS/
> V1_3-20110913-A/OMA-TS-MMS_ENC-V1_3-20110913-A.pdf


OK，Thank you. Lina will ask India QA to capture logs.

However, QA has left the city. Can you check the attachment '7730ffos_mms_multipleread.log' if it is helpful?

answer you question:
> Can test double confirm the message is a normal incoming MMS or a MMS read
> report?

 1、QA Send a MMS from SIM1 to SIM1, MMS was sent and received successfully
   --> Wait for a while, device received the read report
 2、download the read report
   --> after the successful download of read report, another read report was received again.
   Repeat 2, the process keeps on going and going

 So I think the first message is a normal incoming MMS， and the others are all read report.

There are two bugs mentioned above.
[1] When "Read report" was turned off, there should be no read report.
[2] Read a "read report" should not trigger another "read report"

I upload the picture of this issue provided by QA, please check，thanks.

Comment 12

[Kun Tang]

Attachment: MMS_Report_20140617_1.jpg

Comment 13

[Kun Tang]

Attachment: MMS_Report_20140617_2.jpg

Comment 14

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

Attachment: Patch v1: Always Check 'x-mms-read-report' before trying to send read report. r=vyang, a=1.4+

After reviewing current MMS implmentation and the symptom in this carrier, I found some suspicious points:
1. |sendReadReport| is always requested from both Gaia and Gecko without checking if the |x-mms-read-report| of the received MMS is set or not.
2. The read-report in this carrier was formed in a normal incoming MMS instead of a MMS-Read-Report.
3. Hence, when device user sends a MMS to him/her self, a read report will be sent again and again once receive a new MMS to him/her self due the reasons mentioned above.

Hi Kun Tang,

Is it possible to have a try of the attachment patch?
I'd like to double check if this is the root cause of this bug before landing it.

Thanks!

Comment 15

[Kun Tang]

Hi Bevis Tseng

   We must let India QA to try this issue.
   
   We will merge your patch in our code to compile a PAC. So I want to confirm if this patch will cause side effect?

Comment 16

[Julien Wajsberg [:julienw]]

[Blocking Requested - why for this release]: Read reports issue in some carriers, notably in India. When that happens we enter an infinite loop.

Comment 17

[Julien Wajsberg [:julienw]]

Bevis, I don't remember if we already had this feature in v1.3t ?

Comment 18

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

(In reply to Julien Wajsberg [:julienw] from comment #17)
> Bevis, I don't remember if we already had this feature in v1.3t ?
Yes, because solution of Bug 921919 is included in v1.3.

Comment 19

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

(In reply to Kun Tang from comment #15)
> Hi Bevis Tseng
> 
>    We must let India QA to try this issue.
>    
>    We will merge your patch in our code to compile a PAC. So I want to
> confirm if this patch will cause side effect?

No, the patch is quite simple. I've tested it locally.
Please give it a trial.

Thanks!

Comment 20

[Evelyn Hung]

clear my ni because Bevis is helping. Thanks!

Comment 21

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

Comment on attachment 8464516 [details] [diff] [review]
Patch v1: Always Check 'x-mms-read-report' before trying to send read report. r=vyang, a=1.4+

Per discussion offline, this patch is to ensure the read report will only be sent if it was requested in the incoming mms message.

Hi Vicamo,

May I have your time to review this change?

Thanks!
Bevis

Comment 22

[Vicamo Yang [:vicamo][:vyang]]

Comment on attachment 8464516 [details] [diff] [review]
Patch v1: Always Check 'x-mms-read-report' before trying to send read report. r=vyang, a=1.4+

Review of attachment 8464516 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you :)

Comment 23

[Marvin Khoo [:Marvin_Khoo]]

triage result, 1.4+.

Comment 24

[Julien Wajsberg [:julienw]]

Bevis, please remember to ask approval to land on v2.0 too !

Comment 25

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

update try server result:
https://tbpl.mozilla.org/?tree=Try&rev=0497738b0305

Comment 26

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

Comment on attachment 8464516 [details] [diff] [review]
Patch v1: Always Check 'x-mms-read-report' before trying to send read report. r=vyang, a=1.4+

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 921919
User impact if declined: The message sender will receive an unexpected read-report from FFOS device which was not requested when sending. It becomes worse in Airtel, India, that there will be an infinite loop between device and network as mentioned in comment 14 when reading a mms message sent to self.
Testing completed: Y
Risk to taking this patch (and alternatives if risky): No
String or UUID changes made by this patch:NA

Comment 27

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/b2g-inbound/rev/117263eb0550

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/117263eb0550

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/24bc2ae19c59

Comment 30

[Kun Tang]

Attachment: bug1039185.rar

Comment 31

[Kun Tang]

(In reply to Bevis Tseng [:bevistseng] ([e-mail]) from comment #14)
> Created attachment 8464516 [details] [diff] [review]
> Patch v1: Always Check 'x-mms-read-report' before trying to send read
> report. r=vyang, a=1.4+
> 
> After reviewing current MMS implmentation and the symptom in this carrier, I
> found some suspicious points:
> 1. |sendReadReport| is always requested from both Gaia and Gecko without
> checking if the |x-mms-read-report| of the received MMS is set or not.
> 2. The read-report in this carrier was formed in a normal incoming MMS
> instead of a MMS-Read-Report.
> 3. Hence, when device user sends a MMS to him/her self, a read report will
> be sent again and again once receive a new MMS to him/her self due the
> reasons mentioned above.
> 
> Hi Kun Tang,
> 
> Is it possible to have a try of the attachment patch?
> I'd like to double check if this is the root cause of this bug before
> landing it.
> 
> Thanks!

Yes, this is the root cause of this bug. QA check it and now firefox working fine now. 
The attachment of 'bug1039185.rar' is the log, But I think it is no use again.

Thank you very much.

Comment 32

[bhavana bajaj [:bajaj]]

Is this issue reproducible on flame? Adding qawanted to check.

Comment 33

[Julien Wajsberg [:julienw]]

Bhavana, note that this happens with specific carriers only (especially one in India).

Comment 34

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

I was unable to reproduce either issue from comment 0 on Flame using a T-Mobile SIM on a build that should have been before it was fixed.  We do not have SIMs from another carrier that can do read reports.

Environmental Variables:
Device: Flame Master
BuildID: 20140723121905
Gaia: 15c84c943e41ad834640a45e1e1c2ac804168af7
Gecko: 30907d52c4c2
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 35

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

(In reply to Jayme Mercado [:JMercado] from comment #34)
> I was unable to reproduce either issue from comment 0 on Flame using a
> T-Mobile SIM on a build that should have been before it was fixed.  We do
> not have SIMs from another carrier that can do read reports.
> 
> Environmental Variables:
> Device: Flame Master
> BuildID: 20140723121905
> Gaia: 15c84c943e41ad834640a45e1e1c2ac804168af7
> Gecko: 30907d52c4c2
> Version: 34.0a1 (Master) 
> Firmware Version: v123
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Hi,

The symptom in other carrier is that, 
the device sender will always receive a read report by our device even the read report was not requested by the sender.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/b01206224fe8