Using ubertooth, kismet and wireshark isuue

[michaelp123]

Hi, I am using the ubertooth plugin for Kismet. When I open it with wireshark, I get only 14 byte ID field and no payload.

What seems to be the problem?

[dominicgs]

This appears to be the same issue as: https://github.com/greatscottgadgets/libbtbb/issues/36

Do you see the same address as in that issue?

[michaelp123]

[michaelp123]

This is what I see

[dominicgs]

Do these addresses look like the valid lower half of the Bluetooth addresses of nearby devices?

None of them appear to be enquiry packets, but Ksimet has not been able to calculate the UAP yet, so it only has LAP values and is unable to decode any more of the packet. Is it the same at the end of the file?

[michaelp123]

Yes these addresses are valid LAP. But in kismet server console it seems like UAP was discovered:

[michaelp123]

[michaelp123]

So I don't understand the mismatch here.

[dominicgs]

The output shows that it found the UAP after 21 packets. The Wireshark screenshot above shows only the first 16 packets. What do the packets at the end of the file look like?

[michaelp123]

Look the Same. Even after waiting long long time and gathering lots of packets I see the same info in wireshark: only 14byte ID.

[dominicgs]

That's certainly a bug, it should decode the packets once it knows the UAP.

[michaelp123]

So what our next steps should be?

[dominicgs]

At some point I or someone else will need to investigate and fix the bug. We have a release in early March, so hopefully it will be fixed in time for then. I'm surprised that we haven't seen this issue before as the Kismet plugin has been around for 4 or so years, so it will likely take some time to investigate and fix.

[michaelp123]

[michaelp123]

I now used kismet again for 45 minutes, and saw this. In the protocol field, I see bluetooth and also 0xff...

[ohyeahq]

I'm having the same problem, related with libbtbb #36 and ubertooth #92.

I looked into the code (lib/src/bluetooth_piconet.c) and noticed that I didn't get BTBB_CLK27_VALID because btbb_init_hop_reversal() and btbb_winnow() are never called in my case. So I inserted

        btbb_init_hop_reversal(0, pn);
        btbb_winnow(pn);

right after

    if (btbb_piconet_get_flag(pn, BTBB_CLK6_VALID)) {
        btbb_uap_from_header(pkt, pn);

in try_hop() function (as a quick'n dirty hack, I know).

I'm not sure this is the right move, but now I'm getting a lot more than 14 bytes in kismet/ubertooth combo (pcapbtbb), which can be fed into wireshark. One small step. A bad news is that the payload seems encrypted, so this is the dead end. (I was hoping that BT audio's initial inquiry/negotiation, i.e., codec/bitrate info might be w/o encryption ... too bad.)

BTW, I also noticed that AFH support is intentionally disabled in the code. Any hope in the near future? (No push)

Cheeeeeers

[dominicgs]

Where is AFH mode disabled? In Kismet?

[ohyeahq]

Sorry for confusion. I meant this. In lib/src/bluetooth_piconet.c, inside btbb_decode():

    /* Removing this section until we can more reliably handle AFH */

and the following block is commented out.

Cheeeeeeeers

[straithe]

It looks like the question was solved so I am closing this issue. Please re-open this issue or open a new one if you still need assistance.