bluetoe
bluetoe copied to clipboard
C++ Framework to build Bluetooth LE Server (GATT)
This leads to the following tests failing: - LL/CON/PER/BI-05-C - LL/CON/PER/BI-07-C - LL/CON/PER/BV-51-C
test::radio::simulate_connection_event_response() does not take acknowledge correctly into account
It's possible to set any SN or NSN in the simulated received PDUs, the result will be the same. To test correct behavior for the acknowledge scheme on a higher...
Currently, there is no collision detection implemented. - LL/CON/PER/BV-48-C - LL/CON/PER/BV-46-C - LL/CON/PER/BV-47-C
What happens, when Bluetoe is currently waiting for the instance of a running LL procedure and while that time, receives a new / next procedure that has an instance?
While doing some very basic LL testing, there was a situation, where reproducible, the connection got lost, after an update to 2M PHY. But: This happened so far only with...
If a central requests update for an asymmetric PHY update, Bluetoe happily replies with both, 1M and 2M set for both, RX and TX if then the update is applied...
5.1.3.2: During the pause, data PDUs shall not be sent unencrypted to protect the data. Will fail: LL/SEC/PER/BV-03-C
Currently, invalid PDUs (be it invalid length or unknown opcode) are simply ignored. The Core spec requires an error reply. Would fail: - LL/PAC/PER/BI-01-C - LL/PAC/PER/BV-01-C
LL/CON/PER/BI-16-C and LL/CON/PER/BI-08-C will fail, as the requested parameters are not checked.