bluuetooth JustWorks and Eddystone are mutually exclusive?

[OwenBrotherwood]

The background for this issue is to see if there is a mutually exclusively for JustWorks and Eddystone. It is possible one expects to be able to use paired service and Eddystone at the same time which may not be possible. Within the time available, I have tried to obtain some form of basic config.json knowledge as to how the effects of config.json have on wanted or expected or realistic outcome. For a start point, I have used the Eddystone example and it's config.json that works for obtaining Eddystone.

From previous correspondence, and looking at code that uses the micro:bit dal, I surmise that JustWorks requires some form of white list (1) and Eddystone requires no white list (0)

ie: JustWorks and Eddystone are mutually exclusive?

    "microbit-dal": {
        "bluetooth": {
            "enabled": 1,                             # enable bluetooth
            "pairing_mode": 0,                    # no pairing
            "private_addressing": 0,            # Find the doc/spec
            "open": 1,                                  # no pairing needed
            "whitelist": 0,                             # no restriction to access for non paired devices
            "advertising_timeout": 0,           # Eddystone the rest plus some services disabled
            "tx_power": 0,
            "dfu_service": 0,
            "event_service": 0,
            "device_info_service": 0,
            "eddystone_url": 1,
            "eddystone_uid": 0
        },
        "gatt_table_size": "0x600"
    }

[ghost]

They are mutually exclusive but this is not necessarily intended. Initially it was envisaged micro:bits as beacons would be connectionless broadcasters only. That said, there's a flag that lets you advertise such that connections may be accepted so in that scenario, it would make sense to allow pairing (not solely Just Works pairing btw).

So this is a genuine issue I guess, although beacons that accept connections are rare and the Eddystone spec itself recommends not doing this I think.

Given we're allowing code to request connectable advertising though, it's a fair conclusion that we should also allow pairing. Therefore this area needs some refactoring.

[OwenBrotherwood]

Thanks Martin. I was a bit unsure of my findings, but only a bit :)

I reframed with a pull request to pxt-microbit in connection with the default tx power as I remember reading that there was some concerns with childrens privacy (large tx effect spreads further information that may have been exposed by mistake). Is the default power output still an issue? I think default is about 3-4 but I know that some teachers complain about losing connectivity without understanding the principle of the default tx power and that is may be lower than what they expect.

[ghost]

Restricting TX power is not a solution to real privacy issues so I would be against this. I would prefer PXT expose the TX Power property so that individual developers can select it.

The only solutions to privacy issues are to work over an encrypted connection with resolvable private addresses.... but most smartphones don't yet support this address type. The real solution therefore is to not include sensitive information in Bluetooth advertising packets.

[ghost]

Can you post a link to the PR that is concerned with TX power please? And btw the BBC editors (Blocks, TD) restrict the power level. This was a mistake imho and achieves nothing wrt security.

[OwenBrotherwood]

No PR made in connection with a possibility of changing the power in pxt-microbit made due to the perceived restriction on default power level. I believe the default power level is made in the micro:bit and blocks etc may not be overriding (I have to check up on this)

[OwenBrotherwood]

I note that there seems to have been a PR in at least one of the projects using DAL where power level control seems to have been exposed to "user control". I only had time for a quick look, so I didn't check if the power level was set to default 7 or default "whatever DAL has".

[OwenBrotherwood]

@bluetooth-mdw I found something concerning concerns in the spec for accept of connection in connection with possible denial of service. You mentioned it https://github.com/lancaster-university/microbit-dal/issues/251#issuecomment-265459620

A Configuration Mode is necessary because having a continuously connectable Eddystone-URL would allow any passerby to connect to the device and stop the Eddystone-URL from broadcasting. As a consequence a third party could launch a Denial of Service (DoS) attack by permanently connecting to the beacon. For this reason a Eddystone-URL should not be connectable during regular URL Advertising mode.

[OwenBrotherwood]

I have to investigate the comment

(not solely Just Works pairing btw). from https://github.com/lancaster-university/microbit-dal/issues/251#issuecomment-265459620

Does it mean that Eddystone works with JustWorks enabled?

[ghost]

Yep, I wasn't really in favour of supporting connectable Eddystone beacons in micro:bit and in fact initially this was the default. I argued against it.... a bit.... and in the end we settled on making it an argument in the startAdvertising call.

We're not trying to implement a fully EddyStone spec compliant beacon here. We're providing a sufficient implementation for educational purposes and keeping it simple is therefore the order of the day.

Not looked at the ability to pair and be in EddyStone mode. I don't see any of the 'connectable beacon' scenarios as a priority.

[ghost]

p.s. the denial of service issue goes away if pairing is enabled since then the white list prevents unpaired devices from connecting.

[OwenBrotherwood]

I think this is the best: the code implements sufficient aspects of the specs in order to create the experience you write here:

We're not trying to implement a fully EddyStone spec compliant beacon here. We're providing a sufficient implementation for educational purposes and keeping it simple is therefore the order of the day.

[ghost]

Agreed :-)