Closed
Bug 1043856
Opened 10 years ago
Closed 10 years ago
[NFC] When receiver's BT on, receiver sometimes would get file transfer request dialog while NFC transfer file
Categories
(Firefox OS Graveyard :: NFC, defect)
Tracking
(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)
People
(Reporter: ashiue, Assigned: arno)
References
Details
Attachments
(6 files, 9 obsolete files)
Gaia c72257b2d27135bfcd68e89dd584182797784016 Gecko https://hg.mozilla.org/mozilla-central/rev/616e6924cb0b BuildID 20140724160202 Version 34.0a1 STR: Tap 2 phones to share an image Expected result: Share successfully Actual result: Files cannot be shared easily, sometimes, when receiver's BT initial turn on, receiver would get file transfer request dialog.
Reporter | ||
Comment 1•10 years ago
|
||
Reporter | ||
Comment 2•10 years ago
|
||
Reporter | ||
Comment 3•10 years ago
|
||
Reporter | ||
Comment 4•10 years ago
|
||
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?
QA Whiteboard: [COM=NFC]
Reporter | ||
Updated•10 years ago
|
Summary: [NFC] Cannot share files often → [NFC] When receiver's BT on, receiver sometimes would get file transfer request dialog while NFC transfer file
Alison: I took a look at the video. Can you verify that the receiver first showed a notification that the transfer failed and then showed the file transfer dialog? I think I saw it in the video but wanted to double check with you. What is happening is that the receiver times out the transfer request (the timeout is currently 6 seconds). At that point the receiver cancels the file transfer and if the sender then sends the file, the BT transfer app will show the dialog. If that is what is happening, the solution is to increase the timeout that cancels the handover request. I only have one Flame device and I've used an Android device as the second device. The 6 second timeout seemed to be ok in that configuration.
Flags: needinfo?(arno) → needinfo?(ashiue)
(In reply to arno from comment #6) > Alison: I took a look at the video. Can you verify that the receiver first > showed a notification that the transfer failed and then showed the file > transfer dialog? Yes > the BT > transfer app will show the dialog. BT trasnfer dialog shouldn't be shown.
Flags: needinfo?(ashiue)
The receive file dialog is shown because NfcHandoverManager timed out the handshake. I've attached a mini-patch that increases the timeout to 8 seconds. Should I request a review or can you flash a version for Alison to test? Again, I only have one Flame device so I cannot do that test myself.
Attachment #8462526 -
Flags: feedback?(allstars.chh)
Reporter | ||
Comment 9•10 years ago
|
||
[Blocking Requested - why for this release]: 2.0 also can reproduce this issue. Please fix on both code branches. Gaia 0a864988f5dce7f9f3dea9609e8ef054679c30ff Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/2da96d621030 BuildID 20140727160207 Version 32.0
Attachment #8462526 -
Flags: feedback?(allstars.chh)
Assignee | ||
Comment 10•10 years ago
|
||
(In reply to ashiue from comment #9) > [Blocking Requested - why for this release]: > > 2.0 also can reproduce this issue. Please fix on both code branches. Since the 2.0 branch uses the same timeout, this is to be expected.
Assignee | ||
Comment 11•10 years ago
|
||
Attachment #8462526 -
Attachment is obsolete: true
Attachment #8463296 -
Flags: review?(alive)
Comment 13•10 years ago
|
||
Comment on attachment 8463296 [details] [review] Increase handover timeout if this fixes what the real problem..
Attachment #8463296 -
Flags: review?(alive) → review+
Keywords: checkin-needed
Assignee | ||
Comment 14•10 years ago
|
||
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #13) > Comment on attachment 8463296 [details] [review] > Increase handover timeout > > if this fixes what the real problem.. Can't tell is that is supposed to be a question or a comment. The NFC and BT protocols do not share any state information. In certain circumstances race conditions are unavoidable. E.g., when the BT Transfer App receives an incoming file transfer request, it cannot be determined with 100% certainty if that request originated from a NFC handover or not. The timeout can only reduce the likelihood of a race condition but cannot avoid it.
Comment 15•10 years ago
|
||
Master: https://github.com/mozilla-b2g/gaia/commit/6a3e55ac1391a78ee77f247d69bb3f71da43ece9
Status: NEW → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S1 (1aug)
Comment 16•10 years ago
|
||
v2.0: https://github.com/mozilla-b2g/gaia/commit/9369f7f9a4795d7d554c6c1ddb3c7daee3e4f994
Reporter | ||
Comment 17•10 years ago
|
||
I tried file transfer many times on Gaia b67ddd7d40b52e65199478b8d6631c2c28fdf41d Gecko https://hg.mozilla.org/mozilla-central/rev/005424a764da BuildID 20140730160200 Version 34.0a1 Here are the test result: [Both phones BT on - Total 35 times] Pass - 25 Fail - 10 (5 show BT transfer request dialog) [Both phones BT off - Total 35 times] Pass - 33 Fail - 2 (0 show BT transfer request dialog) I think the fail rate still high when BT initial on on both test devices, and the transfer request issue could hit 5 times. Hi Arno, since I could not (until now) hit transfer request dialog issue when BT initial off on both test devices, is timeout the only root cause? My question is why BT initial off do not have the higher probability to hit this problem?
Flags: needinfo?(arno)
Comment 18•10 years ago
|
||
Hi Alison, thanks for your hard working on verifying this bug. Based on your test result, I think we should reopen this bug. Hi arno, do you think you can provide a better solution to fix the problem. Looks like extending the timeout doesn't fix the problem.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 20•10 years ago
|
||
Master: https://github.com/mozilla-b2g/gaia/commit/8377465fb15ff32eb69e46332d73644334109a6c v2.0: https://github.com/mozilla-b2g/gaia/commit/96e9dd793fe5aeea5a144b93f7f448f2fbe95f6d
Flags: needinfo?(ryanvm)
Target Milestone: 2.1 S1 (1aug) → ---
Assignee | ||
Comment 21•10 years ago
|
||
(In reply to ashiue from comment #17) > I think the fail rate still high when BT initial on on both test devices, > and the transfer request issue could hit 5 times. > Hi Arno, since I could not (until now) hit transfer request dialog issue > when BT initial off on both test devices, is timeout the only root cause? > My question is why BT initial off do not have the higher probability to hit > this problem? Alison: first of all thank you for the hard work on testing this patch. Shawn: I only have one Flame device and cannot reproduce Alison's setup. However, I just tried sending a file from Android to Flame via a NFC handover. The Android device is the sender and the Flame device is the receiver (BT enabled on both devices). I managed to send 26 times without any flaw. After that the file transfers consistently failed. The interesting thing is that the Android devices pops open a message saying "Receiver's device does not support large file transfer via beam." Does this tell you something?
Flags: needinfo?(arno) → needinfo?(shuang)
Assignee | ||
Comment 22•10 years ago
|
||
Shawn: I canceled the ni because I dug into the logs and found another problem that is unrelated to BT. Dimi: I am sending files from Android to Flame via a handover. After several successful transfers, nfcd does not send the Handover Select message back to Android anymore. I've attached two logs that show a working and a non-working example. Do a grep on NFC:WriteNDEF in the logs. That is where NfcHandoverManager sends the Handover Select NDEF message back to the peer. In the working log you can see that nfcd receives the message and then actually performs the sending of the Hs record. The non-working log shows that nfcd receives the message but for some reason then stops processing it. STR: - Device 1: Android (Nexus 5, 4.4.4) - Device 2: Flame Gaia: https://github.com/svic/gaia/tree/Bug_1043856 Gecko: 46c9b0371c8c4591e0e8bd5e889a8555e5e1e4ce nfcd: b6f025acd8ead1c3531e1ad62e70849161ed9340 - Enable BT on both devices - Send a picture from Android to Flame via beam - Repeat sending until error occurs (happened for me from somewhere 6-26 attempts)
Flags: needinfo?(shuang) → needinfo?(dlee)
Assignee | ||
Comment 23•10 years ago
|
||
Assignee | ||
Comment 24•10 years ago
|
||
Comment 25•10 years ago
|
||
Hi Arno, From the log I cannot get enough information to know what exactly the problem is. And I update the latest gecko/gaia/nfcd and apply the patch you provided in this bug, I cannot reproduce this bug after trying more than 50 times. I attach a nfcd with more debug information, if you still can reproduce it could you help me replace the nfcd and dump the log for me again ? Thanks for help
Flags: needinfo?(dlee)
Assignee | ||
Comment 26•10 years ago
|
||
I updated to the latest b2g/master as well and used your version of nfcd. I ran into the problem again. Attached are the logs.
Attachment #8465650 -
Attachment is obsolete: true
Attachment #8465652 -
Attachment is obsolete: true
Comment 27•10 years ago
|
||
Hi All, When working on 948823, I've accidently introduced a bug of calling |doConnect| instead of |_doConnect| in NfcHandoverManager. This is already fixed in 2.1, and I've requested uplift for 2.0: https://bugzilla.mozilla.org/show_bug.cgi?id=1046289 From the comments in this bug I suspect it's not related, but in any case I wanted you to be aware of that.
Assignee | ||
Comment 28•10 years ago
|
||
(In reply to Kamil Leszczuk [:kamituel] from comment #27) > When working on 948823, I've accidently introduced a bug of calling > |doConnect| instead of |_doConnect| in NfcHandoverManager. Thanks for the heads up. Shawn already told me about that issue. Fortunately (or unfortunately, depending on your view) this is unrelated to this bug.
Comment 29•10 years ago
|
||
Hi Arno, Thanks for help, according to the log, one nfcd internal thread is stuck. Because the log only contains the info after thread is stuck, so i cannot get enough information. Could you help me dump the log again with the uploaded nfcd v2, and dump the log with "-v threadtime" and dump from beginning to the error occurs. I am sorry that i tried to check it at my side but i just cannot reproduce it.
Comment 30•10 years ago
|
||
Hi there, is the root cause for this bug is related to nfcd? If not, we should file the new bug to track thread gets stuck issue.
Assignee | ||
Comment 31•10 years ago
|
||
(In reply to Dimi Lee[:dimi][:dlee] from comment #29) > Could you help me dump the log again with the uploaded nfcd v2, and dump > the log with "-v threadtime" and dump from beginning to the error occurs. > I am sorry that i tried to check it at my side but i just cannot > reproduce it. Dimi: I can reproduce this with the v2.0 branch. I've used your new debug version of nfcd and created a log as you've requested. I took the complete log since boot. I managed to transfer two files and on the third attempt, I encountered the missing Hs record problem. Hope this helps.
Assignee | ||
Comment 32•10 years ago
|
||
Attachment #8466112 -
Attachment is obsolete: true
Assignee | ||
Comment 33•10 years ago
|
||
I spent some time testing sharing between two Flame devices. I was able to share 35 pictures (BT on) without one failure. I had to increase the connection timeout as I already suggested in comment 8. HOWEVER, we have some issues with the shrinking UI that prevents sharing from working consistently. This is unrelated to this bug and Sid will open a new bug for this. Gecko: 8dc28b29aa49f0e80e513ea3b96ad85b0f283d71 Gaia: https://github.com/svic/gaia/tree/Bug_1043856
Comment 34•10 years ago
|
||
Hi Arno, Thanks for help, I might found the root cause. Could you help use upload nfcd v3 to check if the issue can still be reproduced ?
Attachment #8465947 -
Attachment is obsolete: true
Attachment #8467581 -
Attachment is obsolete: true
Reporter | ||
Comment 35•10 years ago
|
||
Hi Arno, I tried today's 2.0 build with different base images Gaia 7e71fb4d7399e6ca502f252ab259b5462ef41a1d Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/b23198eb9bd5 BuildID 20140805160203 Version 32.0 ************************************************* Full flash from pvt ------------------- [Both phones BT on] Pass - 14 Fail - 21 (17 show BT transfer request dialog) [Both phones BT off] Pass - 13 Fail - 22 (0 show BT transfer request dialog) ------------------- V123 ------------------- [Both phones BT on] Pass - 20 Fail - 15 (13 show BT transfer request dialog) [Both phones BT off] Pass - 13 Fail - 22 (0 show BT transfer request dialog) ------------------- V122 ------------------- [Both phones BT on] Pass - 16 Fail - 19 (18 show BT transfer request dialog) [Both phones BT off] Pass - 15 Fail - 20 (0 show BT transfer request dialog) ************************************************* The test steps are really simple: 1. Flash test device and enable NFC (turn on BT if I test BT on scenario) 2. Go to Camera take a picture 3. Go to Gallery and select the picure 4. Tap 2 phones together to share the image 5. Repeat step4 35 times Do you find any difference between your test and mine?
Assignee | ||
Comment 36•10 years ago
|
||
(In reply to ashiue from comment #35) > Do you find any difference between your test and mine? Yes, the difference is that I've increased the connection timeout for my testing (see comment 33). The patch I already proposed in comment 8 is needed. Since the original patch was backed out again, I will submit another review from Alive.
Assignee | ||
Comment 37•10 years ago
|
||
The connection timeout is needed.
Attachment #8463296 -
Attachment is obsolete: true
Attachment #8468900 -
Flags: review?(alive)
Comment 38•10 years ago
|
||
Comment on attachment 8468900 [details] [review] Increase handover timeout Will we change this 20 more times(joking)?
Attachment #8468900 -
Flags: review?(alive) → review+
Keywords: checkin-needed
Assignee | ||
Comment 39•10 years ago
|
||
(In reply to Dimi Lee[:dimi][:dlee] from comment #34) > Thanks for help, I might found the root cause. Could you help use upload > nfcd v3 to check if the issue can still be reproduced ? Dimi: good news! I no longer get the error with your latest version of nfcd. Nice job! Just out of curiosity: why did the problem only happen from Android to Flame but not between two Flame devices?
Comment 40•10 years ago
|
||
(In reply to arno from comment #39) > (In reply to Dimi Lee[:dimi][:dlee] from comment #34) > > Thanks for help, I might found the root cause. Could you help use upload > > nfcd v3 to check if the issue can still be reproduced ? > > Dimi: good news! I no longer get the error with your latest version of nfcd. > Nice job! Just out of curiosity: why did the problem only happen from > Android to Flame but not between two Flame devices? It seems related to some nci event libnfc-nci received. I would guess the event only triggered by the Android device.
Comment 41•10 years ago
|
||
(In reply to Dimi Lee[:dimi][:dlee] from comment #40) > (In reply to arno from comment #39) > > (In reply to Dimi Lee[:dimi][:dlee] from comment #34) > > > Thanks for help, I might found the root cause. Could you help use upload > > > nfcd v3 to check if the issue can still be reproduced ? > > > > Dimi: good news! I no longer get the error with your latest version of nfcd. > > Nice job! Just out of curiosity: why did the problem only happen from > > Android to Flame but not between two Flame devices? > > It seems related to some nci event libnfc-nci received. I would guess the > event only triggered by the Android device. Create Bug 1050621 to track it
Comment 42•10 years ago
|
||
Master: https://github.com/mozilla-b2g/gaia/commit/4c8c6569f2fded3c610cb6baf2e86355b1004653
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S2 (15aug)
Comment 43•10 years ago
|
||
The timeout is already 9000 on v2.0, so there's nothing to uplift there.
Comment 44•10 years ago
|
||
oh ffs, that's because comment 42 was to v2.0, not master. Master: https://github.com/mozilla-b2g/gaia/commit/8aff4c9d819544ddf8f1fa0928e5bb532aeab617 Arno, in the future, please submit PRs against master.
Reporter | ||
Comment 45•10 years ago
|
||
Hi Arno, I tried full flash 2.0 build Gaia de28796a8956a48bb98ca67df6a33e0622d642d1 Gecko https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/5256345f62bd BuildID 20140810160202 Version 32.0 [Both phones BT on] Pass - 32 Fail - 3 (0 show BT transfer request dialog) [Both phones BT off] Pass - 33 Fail - 2 (0 show BT transfer request dialog) No longer show the BT transger request dialog at 2.0 latest build. I would check 2.1 again after bug 1048093 fixed. And I found a problem when I tried transfer file many times for this issue, I updated at bug 1043878.
Attachment #8468260 -
Attachment is obsolete: true
Attachment #8468064 -
Attachment is obsolete: true
Reporter | ||
Comment 46•10 years ago
|
||
It's good to see the latest 2.1 build also could not reproduce this BT request dialog problem! Gaia 8f955d80d175e52283275d3197e4eae2574b389f Gecko https://hg.mozilla.org/mozilla-central/rev/391f42c733fc BuildID 20140811160202 Version 34.0a1
Status: RESOLVED → VERIFIED
Comment 48•10 years ago
|
||
This issue has been verified successfully on Flame 2.0. See attachment: 1535.MP4 Step: 1. Launch sender Camera, and take a picture. 2. Go to sender Gallery and select the picure. 3. Tap 2 phones together to share the image. 4. Repeat step4 35 times. Actual result: [Both phones BT on] Pass - 35 Fail - 0 (0 show BT transfer request dialog) [Both phones BT off] Pass - 35 Fail - 0 (0 show BT transfer request dialog) Flame 2.0 version: Gaia-Rev 856863962362030174bae4e03d59c3ebbc182473 Gecko-Rev https://hg.mozilla.org/releases/mozilla-2g32_v2_0/rev/e40fe21e37f1 Build-ID 20141207000206 Version 32.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141207.034341 FW-Date Sun Dec 7 03:43:52 EST 2014 Bootloader L1TC00011880
Updated•10 years ago
|
status-b2g-v2.2:
--- → verified
Updated•10 years ago
|
status-b2g-v2.2:
verified → ---
Comment 49•10 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•