Jetson TX2 bluetooth beacon not complete

Hi,

We’re using the Jetson TX2 and its bluetooth chip to pair with a Nuki smart door lock. When doing a discover, I noted that the ‘ServiceData’ values in Nuki’s beacons were not showing up in BlueZ.

In the kernel I see the following warning every time one of these beacons is received:
hci0 advertising data length corrected

Using tcpdump on the Bluetooth interface, I saw that this was received:

    0x0000:  043e <b>1b</b>02 0100 00ad 95ec 72d2 54<b>0f</b> 0201  .>........r.T...
    0x0010:  0615 2166 9a0c 2000 086c 91e4 11b6       ..!f.....l....

Doing the same on my laptop, got me this:

    0x0000:  043e <b>25</b>02 0100 00ad 95ec 72d2 54<b>19</b> 0201  .>%.......r.T...
    0x0010:  0615 2166 9a0c 2000 086c 91e4 11<b>01 5500</b>  ..!f.....l....U.
    0x0020:  <b>e12e a916 ec95 ad</b>d0                      ........

Analysing the EIR data, I noticed following parts:
0201 06
and
1521 669a 0c20 0008 6c91 e411 0155 00e1 2ea9 16ec 95ad

On the Jetson, the second part of the EIR data is cropped to:
1521 669a 0c20 0008 6c91 e411

This leads to the error in the kernel because the indicated length 0x15 (=21) is larger than the remaining number of bytes (11) in the beacon. Because of this, the kernel changes the total EIR data length from 0f (=15) to 03 (=3) and the service data part is completely dropped.

Is there any explanation of why these bytes are not received? Anything I can try to change to help debugging this further?

Thanks in advance,
Niels

Hi Niels,

Could you share the kernel log when this error happens?

Also, does BlueZ give out any log?

Hi,

Thanks for your reply.

The only thing I see in the kernel is this:
[18735.615768] Bluetooth: hci0 advertising data length corrected
[18736.395598] Bluetooth: hci0 advertising data length corrected
[18739.810240] Bluetooth: hci0 advertising data length corrected
[18740.589948] Bluetooth: hci0 advertising data length corrected
[18740.978992] Bluetooth: hci0 advertising data length corrected
[18743.615526] Bluetooth: hci0 advertising data length corrected
[18744.009456] Bluetooth: hci0 advertising data length corrected
[18744.399700] Bluetooth: hci0 advertising data length corrected
[18744.797368] Bluetooth: hci0 advertising data length corrected
[18745.583435] Bluetooth: hci0 advertising data length corrected

That’s one line for every time the Nuki lock sends out the beacon. If you happen to have a Nuki lock to test with, you must put the lock in pairing mode for the error to occur.

BlueZ doesn’t generate any output, since the ServiceData is already removed from the beacon by the kernel.

In general, I would like to know

  1. Does this issue only happen to Nuki lock? Is it okay when pairing with other bluetooth device?
    Could you paste the spec of Nuki lock?

  2. Does this issue happen during “pairing” or the data transmission after the pairing? According to the error log and your description, this issue happens during pairing, right?

  1. I currently only see this issue with the Nuki lock. The lock sends out beacons all the time containing manufacturing data. This works fine.

As soon as you put the lock in pairing mode, it starts sending out different beacons. They still contain the same manufacturing data, but they also contain ServiceData (EIR data type 0x21 - Service Data - 128-bit UUID - see https://www.bluetooth.com/specifications/assigned-numbers/generic-access-profile/). Because some bytes seem to get lost here, the kernel drops this EIR field (it’s length is incorrect) and it is never received in user-space.

You can find the Nuki lock’s Bluetooth spec here: https://developer.nuki.io/page/nuki-smart-lock-api-200/2/

  1. The issue thus happens before pairing. All I’m trying to do is figure out whether the lock is in pairing mode or not. To do so, I have to look at the presence of the ServiceData EIR field. However, since this is currently dropped by the kernel, I have no way to tell if the lock is in pairing mode or not.

Thanks for sharing. We need internal team to help check with this issue.

will update to you if we get something or need more detail.

Also, are you using rel-32.3 + devkit?

We’re using a custom Yocto build (using meta-tegra based on L4T R32.2) on our own board. I will verify with the devkit and latest L4T release tomorrow.

I already checked the Broadcom Bluetooth firmware and it’s the same (sha1sum was the same).

Thanks. Waiting for your result on devkit.

I just tested this on the Jetson TX2 devkit with L4T R32.3.1 and the issue is present there as well.

Do you have any update on this?

Still discussing this with our internal team. Thanks for your patience.

Hi,

Sorry for late response. Could you share below data for us to check?

1: install hci dump using “sudo apt-get install bluez-hcidump”
2: Start capturing snoop logs using “sudo hcidump -w test.cfa”
3: Then start use case scenario where issue is observed
4: Once issue is observed stop capturing snoop logs and share same to check further on this.

Hi nielsuf364,

Any update?

Hi,

Sorry for the wait. I didn’t have access to a devkit until now.

I executed the following scenario:

  1. Start hcidump with “sudo hcidump -w test.cfa”
  2. Put the Nuki lock in pairing mode (by long pressing the button on the lock)
  3. Add the Nuki device to the kernel’s list of devices that it scans for passively: “sudo btmgmt add-device -a 0x00 -t 0x01 54:D2:72:EC:95:AD”
  4. Wait a while. I made sure dmesg showed the error at least a few times.
  5. Remove the Nuki device from the kernel’s list of devices: “sudo btmgmt del-device -t 0x01 54:D2:72:EC:95:AD”
  6. Stop hcidump (ctrl+c)

The dump can be found here: https://we.tl/t-HzDPEokVU1

Any update on this?