Usage error after compiling with USE_PCAP=ON

[maximcherny]

Hi,

I managed to compile both bbtb and ubertooth with the USE_PCAP=ON, as I am quite interested in being able to create standard pcap files from ubertooth-rx and the likes. I can see the new -q option available for ubertooth-rx, but when I try the following:

ubertooth-rx -q bt.pcap

I get:

PCAP error:: bt.pcap: link-layer type 255 isn't supported in savefiles
ubertooth-rx: btbb_pcap_create_file: : Success

Any pointers greatly appreciated, thanks in advance. Or am I running too bleeding edge?

[dominicgs]

You're definitely running very bleeding edge code! I'm not sure that it's very well tested and I know that the Wireshark plugin doesn't support the new file format yet.

The PCAP error is probably due to your installed libpcap being from before we were assigned out DLT. I'm not completely sure we need libpcap for everything we need to do, so maybe this can be fixed. In the meantime, perhaps try running the latest git version of libpcap?

[maximcherny]

Thanks for your reply. An older libpcap version was to blame indeed! I did a fresh install of all the latest and the error went away.

However, when I try and open the capture in Wireshark, packets are not being dissected, as also discussed in #13 due to missing WTAP_ENCAP = 161.

I can compile the btbredr plugin and the dissection then happens, but would you classify it as "production-ready"?

[dominicgs]

I believe that the dissector still needs a lot of work, so I would not class it as "production ready" yet.

How much dissection is happening? Would you be willing to share a pcap file?

I'll admit, it's been a few months since I worked on this code, so my memory may be failing me slightly, but I didn't think it worked yet.

[maximcherny]

I am happy to share the capture file, the one I have got at this point is a mere 7000-odd packets 22 bytes each collected via passive ubertooth-rx with no LAP/UAP following. I also plan on getting additional captures over the next couple of days, maybe the next one could be more valuable though.

Naturally, only LAPs are present and no "real" data payloads. The encouraging thing is that btbredr seems to dissect all the basic attributes, so perhaps it's not too far off?

[dominicgs]

That may be as far as I got with the dissector. The real problem here is that without knowing the UAP, we can't be sure that the header was correctly decoded.

Have you managed to capture anything with ubertooth-rx while specifying the LAP? That should attempt to discover the UAP and correctly decode the packet headers.

[maximcherny]

Yes, I have been able to follow the specific LAP to capture what appears to be data packets, some over 360 bytes. Only the metadata and packet header are being dissected and I can also see the UAP value. Unfortunately, there are no additional / new sections that I can see in the dissected format even for those packets.

I'm happy to help, perhaps not actually writing C as that is not one of my skill areas, but I can definitely assist with testing etc.

[dominicgs]

Could you send me that PCAP file and I'll take a look at how the dissector handles it.

[maximcherny]

Yep, e-mailed to you.

[mikeryan]

@dominicgs @maximcherny did you make any noteworthy progress on this issue?

[maximcherny]

Sample PCAP provided, haven't heard back yet... I'm happy to organise more captures if that will help with dissector finalisation.

As far as the original bug goes, the workaround is to use the latest version of all dependencies.

[dominicgs]

The btbredr plugin now builds without needing the latest libpcap.

The dissector parses the packet headers but does not yet parse the packet payloads.

[straithe]

I'm going to close this for now 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.