Join GitHub today
Fix cut off scan buffer. #740
Pull Request Overview
This pull request fixes a bug in the ble-passive-scanning functionality for the nrf52 board.
It was tested manually in userspace by sending packets with service data/manufacturer data with different lengths. Service data is now copied to the scanning buffer completely.
TODO or Help Wanted
As unsafe code has been modified a code review from the kernel perspective would be very much appreciated.
Hrm... This is correct since we set PCNF0 to include a 1-byte
However, there are some confusing issues looking further into the current implementation. Specifically, I believe the on-air length field should be set to 6-bits, not 8 as it is currently set, and s1 should be 2 bits, instead of 0. We are currently saved by the fact that the last 2 bits of the header will always be zero since they are reserved for future use.
Moreover, we're passing up a buffer with a hardware specific structure (i.e. it has 1-byte
First of all thanks @torfmaster for fixing this bug!
Yes, I think I did this because to simply radio buffer management a while back. But still I don't understand this, are you saying that other stacks are including to S1 field and adds another byte in the payload? It is still a pretty ugly way to determine the number of bytes received, i.e, reading the header but because the hardware don't provide anything else I think this is the way to go.
Create an issue I think we need a RFC inorder to construct a better HIL because it is very brute-force at the moment. I was to before I arrived in Berlin but now I don't have that much over time and motivation.
By packed are you referring to a
But still I think we need to specify the HIL should more or less corresponds to the interfaces in the spec, especially clear interfaces between controller and host. This makes is hard to implement new features to stack. Maybe, you and the thesis students can come up with something?
Otherwise, I suspect that we will end-up with two different BLE drivers!
So, the S0 and S1 fields are not really meaningful in BLE. They seem to be a way for the Nordic hardware to support both BLE and their own proprietary protocol (which I'm guessing has a different header format) in the same hardware controller.
The BLE header for advertising packets consists of 8 bits for the PDU type and
In the hardware, S0, S1 and Length are adjustable length fields. They always show up in memory as a single byte (unless S! is configured to not appear), but they can correspond to different sizes in on-air packets. So, for an advertising packet, you'd really want to configure S0 to be 8-bits, Length to be 6-bits, and S1 to be 0-bits.
But importantly, the memory buffer that's gets filled by the DMA will not contain a packed header, but a separate byte for each included field. It's highly likely that other hardware won't do the same thing, and instead just copy the on-air packet as-is, so it's seems suboptimal to have an interface that relies on this property.