bluetooth4/beacon_eddystone_url_hci0 always fails

[Leon Liao]

The bluetooth4/beacon_eddystone_url_hci0 test case always fails.

When this test case was running, although "LE Set Scan Enable" and "LE Set Advertise Enable" was set, but the bluetooth still can not get the advertise information.

But, when the Settings stays in bluetooth page, the advertise information is got.

[Jonathan Cave (jocave)]

Can you explain why this is a bug with checkbox? What is the expected behaviour?

Note that this job was developed for IoT systems orginially.

[Leon Liao (lihow731)]

This test case always failed in desktop and notebook machines.
But, when we open the bluetooth settings then run this test case, this test case will be passed.

The expected behaviour: This test case should be run without any extra action (ex: open the bluetooth settings).

[Sylvain Pineau (sylvain-pineau)]

Please note that even if I wrote this test for IoT initially it also was quickly adopted for desktop testing. We do run it as part of kernel SRU in Cert lab:

E.g: https://certification.canonical.com/hardware/201907-27241/submission/189913/

But in Lab everything runs using checkbox remote and the checkbox service on the SUT is invoked by systemd as root. How do you run yours?

[Leon Liao (lihow731)]

We use autostart to invoke the test plan that nested_part client-cert-auto.
During the test, we enable `sudo` without password.

[Leon Liao (lihow731)]

We are buying the new beacon broadcast devices that will be set near the SUTs.
Let this bug status stay at incomplete until the issue occured again when beacon broadcast device is near by the SUT.

[Leon Liao (lihow731)]

The attached file is the traces in btsnoop format when this bug failed.

[Leon Liao (lihow731)]

The attached file is the traces in btsnoop format when the Settings stayed on bluetooth tab and the result is passed.

[You-Sheng Yang (vicamo)]

Good, then you can easily find following errors by `btmon -r btsnoop-*.log` in both cases, which clearly gives it could be a flaw in the init sequence of aioblescan, most likely be a duplicate of bug 1893176, bug 1896858:

< HCI Command: LE Set Scan Parameters (0x08|0x000b) plen 7 #1 [hci0] 9.480545
        Type: Active (0x01)
        Interval: 10.000 msec (0x0010)
        Window: 10.000 msec (0x0010)
        Own address type: Public (0x00)
        Filter policy: Accept all advertisement (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #2 [hci0] 9.615793
      LE Set Scan Parameters (0x08|0x000b) ncmd 1
        Status: Command Disallowed (0x0c)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #3 [hci0] 9.615903
        Scanning: Enabled (0x01)
        Filter duplicates: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #4 [hci0] 9.616670
      LE Set Scan Enable (0x08|0x000c) ncmd 1
        Status: Command Disallowed (0x0c)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #5 [hci0] 19.491459
        Scanning: Disabled (0x00)
        Filter duplicates: Disabled (0x00)
@ RAW Close: checkbox-suppor {0x0003} [hci0] 19.498046
> HCI Event: Command Complete (0x0e) plen 4 #6 [hci0] 19.627648
      LE Set Scan Enable (0x08|0x000c) ncmd 1
        Status: Command Disallowed (0x0c)
< HCI Command: LE Set Advertise Enable (0x08|0x000a) plen 1 #7 [hci0] 19.627696
        Advertising: Disabled (0x00)
> HCI Event: Command Complete (0x0e) plen 4 #8 [hci0] 19.628745
      LE Set Advertise Enable (0x08|0x000a) ncmd 1
        Status: Command Disallowed (0x0c)

[You-Sheng Yang (vicamo)]

Possible solutions are:

1. Fix in device firmware and let a BT 5.1 device support 5.0 commands. This is against Bluetooth spec "3.1.1 Legacy and extended advertising":

  If, since the last power-on or reset, the Host has ever issued
  a legacy advertising command and then issues an extended
  advertising command, or has ever issued an extended
  advertising command and then issues a legacy advertising
  command, the Controller shall return the error code Command
  Disallowed (0x0C).

So basically mixing legacy and extended commands is not an option. aioblescan must follow how kernel has initialized the device.

2. Pull https://github.com/frawau/aioblescan/pull/30 into checkbox aioblescan. This PR was abandoned because it will introduce API changes to aioblescan, which has some, if not many, down stream projects.

3. Reimplment EddyStone URL scanning by checking ServiceData exposed by bluetoothd DBus API. See https://gitlab.com/vicamo/blasda/-/blob/wip/blasda/__main__.py . This will assure we only have one Bluetooth daemon controlling the bluetooth stack, so such mixing legacy & extended scan commands will no more happen.

[Jonathan Cave (jocave)]

I think the implementation has changed since the last time this bug was commented on. I can run this test on my desktop PC without any workarounds like opening the Settings dialog.

--------------[ Running job 1 / 1. Estimated time left: 0:00:10 ]---------------
[ Test system can get beacon EddyStone URL advertisements on the hci0 adapter ]-
ID: com.canonical.certification::bluetooth4/beacon_eddystone_url_hci0
Category: com.canonical.plainbox::bluetooth
... 8< -------------------------------------------------------------------------
Enter sudo password:

Eddystone beacon detected: URL: http://mytest.com/ <mac: 52:c4:98:76:05:85> <rssi: -66>
------------------------------------------------------------------------- >8 ---
Outcome: job passed

Could you confirm that you are using the latest version of checkbox-support and have an Eddystone Beacon within range of the devices under test?

[Jonathan Cave (jocave)]

As there are a number of examples of the test now working in SRU runs I'm going to set this to Fix Released.

[jeremyszu (os369510)]

@Jonathan,

thanks for sharing the information.
Since Leon is not in Canonical anymore, I will take over to verify this issue in our sanity environment.
Please allow me to leave oem-priority here and I will arrange the time to verify it and change the status here.

[Jonathan Cave (jocave)]

Thanks Jeremy, please make sure you have a Beacon within range of a device and let us know if the job now passes for you.

For reference the MR related to this test is:
https://code.launchpad.net/~pwlars/checkbox-support/+git/checkbox-support/+merge/402529

[Timo Aaltonen (tjaalton)]

what's the point of this bug? it's getting new 'originate-from-NN' tags

[jeremyszu (os369510)]

I believe we were not meet this issue after moving DUTs from taipei-101 to eongher-lab.

Let's open this bug if it happens again.

BTW, reply to comment#14:
the tag is added by bot because we add this test case to a known-issue list.