Corona Warn App-detection

[AugustQu]

besides the rebooting of the device (caused by a watchdog-timer) I encountered the following problem:

the code does not properly detect the devices.

I made the following tests:

1. with RamBLE

2. with this code https://github.com/kmetz/BLEExposureNotificationBeeper (modified a little bit)

3. with the code from here

the case #3 delivered approx. 5 apps found.
The case #1 and #2 delivered both approx. 50 apps found. Comparing the results showed they are almost identical, which means a device found by RamBLE is also found by #2 (and vice versa).

How to explain the difference to the very low number of #3? By the reboots?

[cyberman54]

I think either the code is erraenous, e.g. the string compare for the payload does not match, or the BLE payload does not carry the assumed contents.

I also see far too low CWA matches, while my device runs for many hours and never reboots.

[AugustQu]

here are some results of a test I did today:

[2020-09-16 12:31:25] [E][corona.cpp:39] cwa_clear(): AQ cleaning everything: old=5 (113)
[2020-09-16 12:32:25] [E][corona.cpp:39] cwa_clear(): AQ cleaning everything: old=5 (148)
[2020-09-16 12:33:25] [E][corona.cpp:39] cwa_clear(): AQ cleaning everything: old=2 (164)
[2020-09-16 12:34:25] [E][corona.cpp:39] cwa_clear(): AQ cleaning everything: old=2 (192)
[2020-09-16 12:35:25] [E][corona.cpp:39] cwa_clear(): AQ cleaning everything: old=3 (219)
[2020-09-16 12:36:25] [E][corona.cpp:39] cwa_clear(): AQ cleaning everything: old=2 (235)

topic #1: the last number is the number of BLE-devices found. It is not set back to zero. In the code I found the define COUNTERMODE. Setting this to 0 does not change anything.

topic #2: the number of Corona-apps found is very low (found in old=XX).

topic #3: after reducing the number of lines output I did not encounter any crashes or reboots.

[AugustQu]

compare my results to the numbrs collected with the code mentioned in the beginning of this thread:

[2020-09-16 12:40:11] total stored : 47 (of 154)
[2020-09-16 12:41:11] total stored : 41 (of 135)
[2020-09-16 12:42:12] total stored : 45 (of 137)
[2020-09-16 12:43:12] total stored : 44 (of 136)
[2020-09-16 12:44:12] total stored : 38 (of 135)

the last line means: 38 Corona-apps found of 135 BLE-devices found.

this sounds more reasonable (but I did not encounter 135 people in about 30m around me).

[cyberman54]

but where's the bug?

[AugustQu]

@cyberman54
I just made some modifications to the code. Can you please check them on some place on your side.

In my tests here the values look better now. Comparing it with the numbers RaMBLE delivers the values sound plausible.

[cyberman54]

Tested & seems to work! Merged.

[AugustQu]

not only does it work, the numbers look reasonable.

It was a bit of work to find the cause. The first version look for the bytes 0x3, 0x3, 0x6f, 0xfd in the beginning of the advertisement-data. This was correct but other possible announcements are possible (which it didn't detect).

Now it looks for the bytes 0x16, 0x6f, 0xfd somewhere in the advertisement. Please look in the picture for the details.

The length-indicator (0x13) seems to be wrong, in most cases it is 0x17.

[cyberman54]

Can we have false positives, as long as we decode only a part of the UUID payload?