[flame][Bluetooth] Device could not keep BT's rename and paired devices after reboot

VERIFIED FIXED in Firefox OS v1.4

Status

Firefox OS
GonkIntegration
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Alison Shiue, Assigned: viralwang)

Tracking

unspecified
2.1 S3 (29aug)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:1.4+, b2g-v1.3 unaffected, b2g-v1.4 verified, b2g-v2.0 verified, b2g-v2.1 verified)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

3 years ago
Gaia      fadfafa17f5175203b8b9457bfb95e5816f54f58
Gecko     https://hg.mozilla.org/mozilla-central/rev/75fe3b8f592c
BuildID   20140728160201
Version   34.0a1
Device    Flame


STR:
1. Go to Settings -> Bluetooth
2. Press Rename my device to rename, ex "Flame A"
3. Paired another phone and a BT headset (show on paired devices area)
4. Reboot device
5. Go to Settings -> Bluetooth check

Expected result:
1. Device name should still be "Flame A"
2. All paired devices are still exist on paired devices area

Actual result:
1. Device name change back to default name
2. All paired devices are gone
(Reporter)

Updated

3 years ago
QA Whiteboard: [COM=Bluetooth]
Can you confirm the bluetooth address of the device be consistent?
Flags: needinfo?(ashiue)
This happened many times the specific partition been erased and cause bluetooth address be changed everytime after booting up.
(Reporter)

Comment 3

3 years ago
Yes, the bluetooth address changed after reboot device.
Flags: needinfo?(ashiue)
You might need to ask PM to restore that partition. :( I cannot help much about this problem. There is a partition storing bluetooth address, if that partition is gone, random address will be generated every time.
(Reporter)

Comment 5

3 years ago
Hi Francis,
Could we fix this issue?
Flags: needinfo?(frlee)
(Reporter)

Comment 6

3 years ago
[Blocking Requested - why for this release]:
blocking-b2g: --- → 2.1?

Comment 7

3 years ago
hi ashiue,

i can not reproduce this issue on base image V123 (v 1.3), my Flame's BT is still named as ''Flame A'' and paired device still exist.

it's hard to convince me that this is a vendor issue, since shipping build doesn't have this issue. it could be related to m-c you have flashed.

loop Taipei QA mike.
Flags: needinfo?(frlee)
QA Wanted for branch checks.
Keywords: qawanted
I used the STR in Comment 0 to reproduce this bug.  Issue did not reproduce using either "Restart and Power Off" to reset the connected device. I tested the listed build (20140728160201) and all branches listed below. 

Issue DOES NOT occur on Flame 2.1, 2.0, 1.4, and Buri 2.1

Device: Flame Master
Build ID: 20140804041427
Gaia: af9a0a24fb9f4c5ced3602bc14053bd49b136344
Gecko: 71497ed2e0db
Version: 34.0a1 (Master)
Firmware Version: v122
-------------------------------------------------------------

Device: Flame 2.0
Build ID: 20140804060132
Gaia: 4ab7384db7aee130be165a699472cc19405a4456
Gecko: 5e94ab16ec71
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
-------------------------------------------------------------

Build ID: 20140730110705
Gaia: 142953262d2cb031e3db217206edc3507580b0df
Gecko: 3c780088aae4
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0
-------------------------------------------------------------

Device: Buri Master
Build ID: 20140804041427
Gaia: af9a0a24fb9f4c5ced3602bc14053bd49b136344
Gecko: 71497ed2e0db
Version: 34.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
QA Whiteboard: [COM=Bluetooth] → [COM=Bluetooth] [QAnalyst-Triage?]
status-b2g-v1.3: --- → unaffected
status-b2g-v1.4: --- → unaffected
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → unaffected
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: ddixon
comment 7 and comment 9 indicate this issue is a no-repro. It might be appropriate to close as works-for-me or it also might be specific to the BT device being used by the reporter.
QA Whiteboard: [COM=Bluetooth] [QAnalyst-Triage?] → [COM=Bluetooth] [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)

Updated

3 years ago
QA Whiteboard: [COM=Bluetooth] [QAnalyst-Triage+] → [COM=Bluetooth] [QAnalyst-Triage+][lead-review+]
(Reporter)

Comment 11

3 years ago
After checking again, this is not a vendor issue since this problem only happens when full flash pvt build.
Hi Vance,
I remembered you have checked with partner about this. Any idea? Maybe now full flash pvt build can cause that partition been erased?
Flags: needinfo?(vchen)
Flags: needinfo?(vchen)
See also: bug 1017442
See Also: → bug 1017442
https://bugzilla.mozilla.org/show_bug.cgi?id=1017442#c19
Yes, looks like some old Flame devices will have this issue once you flash the device from a older software version to a newer one. Due to the difference of partition table, the traceability partition will be wiped out hence the BT Mac address will be gone. As a result, each time the device boot up, it will generate a new BT MAC address.

So youlong, my questions for you are:

1. Can we fix in the later release that if during the first boot up, we find that there is no BT MAC address in the traceability partition, we generate a new BT MAC address and permanently write that into traceability partition?

2. I assume that all the flame devices end users buy from the website will have permanent BT MAC address, right?

Thanks!

Vance
Based on Comment 14, this is something depend on flame firmware.
This required our partner to provide response anyway. And I think we shall probably track on bug 1017442 due to this might be related to proprietary code.
ok, I just followed the same STR after flashing the latest base image and everything works as expected. Bluetooth address didn't change after reboot and paired devices were still there as well. Alison, mind checking again?

If this is the case, IMHO this is a partner specific issue.
Flags: needinfo?(ashiue)
(Reporter)

Comment 18

3 years ago
This issue always reproduce when full flash our image. According to Shawn's finding, this issue might caused by flashing pvt userdata partition.
Flags: needinfo?(ashiue)
(In reply to ashiue from comment #18)
> This issue always reproduce when full flash our image. According to Shawn's
> finding, this issue might caused by flashing pvt userdata partition.

Thanks, Alison.

I talked to Viral from Gonk team about this and we had done certain tests last week. However we can't still find a rule of how this happen. Since it's not related to Gaia/Gecko/Gonk Bluetooth, I'm going to re-assign the component to GonkIntegration. Besides, hand over to Viral for keeping track of this.
Component: Bluetooth → GonkIntegration
(Assignee)

Comment 20

3 years ago
Created attachment 8471277 [details] [review]
Bug 1045504 - add trace_util in extract-files.sh to load BT MAC address
Attachment #8471277 - Flags: review?(kli)
Explainer from Viral:
trace_util (which is under /system/bin) will load traceability partition MAC address data section to /data/param/*.
This is why after erasing userdata partition, we don't have static address, because in our PVT build /system/bin/trace_util is missing. However, the original build is with trace_util, so address and config under /data/param will be generated whenever boot-up.
Comment on attachment 8471277 [details] [review]
Bug 1045504 - add trace_util in extract-files.sh to load BT MAC address

This is a partner's util. We need to extract it.
Attachment #8471277 - Flags: review?(kli) → review+
Duplicate of this bug: 1017442
Note: It also depends on kernel module which handles mac address.
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #24)
> Note: It also depends on kernel module which handles mac address.

We need to merge kernel change anyway.
(Assignee)

Updated

3 years ago
Blocks: 1004195
(Assignee)

Comment 26

3 years ago
Here's my test result about the boot.img:

1) t2m zimage + t2m ramdisk + moz dt => good
2) t2m zimage + moz ramdisk + moz dt => bad
3) moz zimage + t2m ramdisk + moz dt => good
4) moz zimage + moz ramdisk + moz dt => bad

It looks like our ramdisk make the BT address abnormal
Need more time to find out the difference.

Note:
the t2m part means the images we have in v123 release.
the moz part means the images we build after ./config.sh flame
(Assignee)

Comment 27

3 years ago
Created attachment 8475778 [details] [review]
Bug 1045504 - add trace_util in extract-files.sh to load BT MAC address(v2)

Hi Seinlin,

I should also update init.target.rc to make trace_util works.
Could you please help to review the updated patch?
Thanks.
Assignee: nobody → vwang
Attachment #8471277 - Attachment is obsolete: true
Attachment #8475778 - Flags: review?(kli)
Comment on attachment 8475778 [details] [review]
Bug 1045504 - add trace_util in extract-files.sh to load BT MAC address(v2)

It looks good. I left comment on github, could you update the PR before check-in? Thanks!
Attachment #8475778 - Flags: review?(kli) → review+
(Assignee)

Comment 29

3 years ago
Already update the PR for check-in.
Keywords: checkin-needed
status-b2g-v1.4: unaffected → affected
status-b2g-v2.0: unaffected → affected
status-b2g-v2.1: unaffected → affected
[Blocking Requested - why for this release]: 
Without this fix "WiFi MAC/BT MAC/IMEI" will use a random value in every boot.
blocking-b2g: 2.1? → 1.4?
Master: https://github.com/mozilla-b2g/device-flame/commit/7dfad27ab7119ce820fc12f9e8029f0b73df4011
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-b2g-v2.1: affected → fixed
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S3 (29aug)
(In reply to Kai-Zhen Li from comment #30)
> [Blocking Requested - why for this release]: 
> Without this fix "WiFi MAC/BT MAC/IMEI" will use a random value in every
> boot.

This is a low risk fix and only need to be merged into flame device config.
Summary: [Bluetooth] Device could not keep BT's rename and paired devices after reboot → [flame][Bluetooth] Device could not keep BT's rename and paired devices after reboot
Whiteboard: [POVB]
[Blocking Requested - why for this release]:

For flame only
blocking-b2g: 1.4? → 2.0?

Updated

3 years ago
blocking-b2g: 2.0? → 2.0+
FWIW, POVB on the whiteboard pretty much guarantees this won't get uplifted on our end...
Sorry to make you confused. This is Flame specific source code. Supposedly, it should from partner side but now, it is hosted and maintained on our github by ourselves for some reason. 
Remove POVB from whiteboard as we need to uplift this fix to v2.0 branch.
Whiteboard: [POVB]
v2.0: https://github.com/mozilla-b2g/device-flame/commit/cb9203fc40777393bf0bfa30445b4b70dd192f9a
status-b2g-v2.0: affected → fixed
[Blocking Requested - why for this release]:
Flame manifest is also available in v1.4 branch and it is used to do comparison test. If this fix can be uplifted to v1.4 will be better.
blocking-b2g: 2.0+ → 1.4?
KaiZhen, can you take care of 1.4 as you suggested.

Thanks
blocking-b2g: 1.4? → 1.4+
init.target.rc doesn't exist on the v1.4 branch, so I guess that makes the uplift a bit more involved.
Flags: needinfo?(vwang)
Keywords: branch-patch-needed
Also, per the changes being announced today, this will need approval-gaia-v1.4 requested on it before it can land (even though it has blocking status).
Duplicate of this bug: 1062061
(Assignee)

Comment 42

3 years ago
Created attachment 8483335 [details] [review]
the is PR for v1.4

NOTE: 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 #): N/A
[User impact] if declined: Without this fix "WiFi MAC/BT MAC/IMEI" will use a random value in every boot.
[Testing completed]: Yes. verified on flame
[Risk to taking this patch] (and alternatives if risky): Low
[String changes made]: None
Attachment #8483335 - Flags: approval-gaia-v1.4?
Flags: needinfo?(vwang)
Keywords: branch-patch-needed

Updated

3 years ago
Attachment #8483335 - Flags: approval-gaia-v1.4? → approval-gaia-v1.4+
v1.4: https://github.com/mozilla-b2g/device-flame/commit/74c423c5297e22d6f5ea718b5911dbe33bc7876e
status-b2g-v1.4: affected → fixed
See Also: → bug 1060996
(Reporter)

Comment 44

3 years ago
Verified on:

[master]
Gaia      72262d054ffa5d0d2b5a0033f713149281511aea
Gecko     https://hg.mozilla.org/mozilla-central/rev/4f2cac8d72da
BuildID   20140917160215
Version   35.0a1

[v2.1]
Gaia      379e68fe729a684fa2fcddb30ea1e65508db73e1
Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/7ff763eb328b
BuildID   20140918000204
Version   34.0a2

[v2.0]
Gaia      31434a3949556171f3565ca47ac2b44e810e95e6
Gecko     https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/cfedc95605d4
BuildID   20140918000201
Version   32.0

[v1.4]
Gaia      efa2b8cb095407df942fee7732a5547c7034ef9b
Gecko     https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/a7f7eaf3f682
BuildID   20140918000205
Version   30.0
Status: RESOLVED → VERIFIED
Created attachment 8529617 [details]
Verify_Video_Flame.MP4

This issue has been verified successfully on Flame 2.0 & 2.1.
See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/10

Flame v2.0 version:
Gaia-Rev        f9d6e3d83c3922e9399a6c27f5ce4cdd27bdfd05
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/45112935086f
Build-ID        20141126000203
Version         32.0

Flame v2.1 version:
Gaia-Rev        db2e84860f5a7cc334464618c6ea9e92ff82e9dd
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/211eae88f119
Build-ID        20141126001202
Version         34.0
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
status-b2g-v1.4: fixed → verified
You need to log in before you can comment on or make changes to this bug.