search

greatscottgadgets / ubertooth

Software, firmware, and hardware designs for Ubertooth
https://greatscottgadgets.com/ubertoothone/
GNU General Public License v2.0
1.92k stars 430 forks source link

Are the Ubertooth Limitations (according to the Kismet docs) accurate? #447

Closed atroche closed 3 years ago

atroche commented 3 years ago

Hello :)

In this part of the Kismet docs it says:

The Ubertooth One truncates all packets to a maximum of 50 bytes; packets larger than 50 bytes will be discarded and ignored because it is not possible to validate the checksum.

and

The Ubertooth One firmware (as of 2019-12) appears to have issues setting channels in BTLE mode, leading to frequent firmware crashes which require the USB device to be removed and re-inserted. Kismet currently disables channel hopping on the Ubertooth One, and defaults to advertising channel 37.

I couldn't find any info anywhere else about the 50 byte limit packet. Is it a hardware restriction? Is there any plan to remove it?

As for the channel setting issues and the crashes requiring re-insertions, are those known problems? Have they been fixed in newer versions of the firmware?

Thanks!

atroche commented 3 years ago

I suppose this is an indication that the packets really do get truncated:

image

(Just given that the length field in the header is larger than the actual packet length.)

BG7YWL commented 3 years ago

What hardware version of Ubertooth One are you using?

kitlith commented 3 years ago

It appears to be accurate, here's the source: https://github.com/greatscottgadgets/ubertooth/blob/d1feeccbd2fba266695a0052caab872ca5bcc263/firmware/bluetooth_rxtx/le_phy.c#L743-L746 that function contains: https://github.com/greatscottgadgets/ubertooth/blob/d1feeccbd2fba266695a0052caab872ca5bcc263/firmware/bluetooth_rxtx/le_phy.c#L766 and DMA_SIZE is defined as 50 here: https://github.com/greatscottgadgets/ubertooth/blob/d1feeccbd2fba266695a0052caab872ca5bcc263/host/libubertooth/src/ubertooth_interface.h#L30

it sounds like this is not an actual hardware limitation, but simply incomplete implementation, but I don't know what complexities may be present.

off the top of my head we could maybe split bluetoooth packets into multiple usb transfers and then recombine them on the host, but that may increase the risk of filling up the usb fifo

edit: it looks like that's roughly what the btbr firmware does for regular bluetooth: https://github.com/greatscottgadgets/ubertooth/blob/d1feeccbd2fba266695a0052caab872ca5bcc263/firmware/btbr/src/drivers/ubertooth_usb.c#L361-L377

mossmann commented 3 years ago

it sounds like this is not an actual hardware limitation, but simply incomplete implementation, but I don't know what complexities may be present.

Yes, it is a firmware limitation, not a hardware limitation.

I'm not sure about the firmware crashes, but please open a new issue for that if you encounter them.

straithe commented 3 years ago

I'm going to close this as there hasn't been a response in a while, but please re-open this issue or open a new one if you still need assistance.