kismet_cap_nrf_52840 not working

[defencore]

nRF52840 firmware: 4.0.0 & 3.1.0 from nRF Sniffer for Bluetooth LE works great with wireshark but can't run with kismet

dmesg

[27460.210143] usb 1-4: new full-speed USB device number 56 using xhci_hcd [27460.369811] usb 1-4: New USB device found, idVendor=1915, idProduct=522a, bcdDevice= 2.04 [27460.369822] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [27460.369828] usb 1-4: Product: nRF Sniffer for Bluetooth LE [27460.369833] usb 1-4: Manufacturer: ZEPHYR [27460.369838] usb 1-4: SerialNumber: A9F59A9D07C288C4 [27460.372092] cdc_acm 1-4:1.0: ttyACM0: USB ACM device

kismet_cap_nrf_52840 --connect 127.0.0.1:3501 --tcp --source=nrf52840:device=/dev/ttyACM0

INFO: Connected to '127.0.0.1:3501'... INFO: 127.0.0.1:3501 starting capture...

kismet --version

Kismet 2021-08-R1

kismet

INFO: Saving packets to the Kismet database log. INFO: Starting Kismet web server... INFO: (DEBUG) Beast server listening on 0.0.0.0:2501 INFO: New remote source nrf52840 (53640727-0000-0000-0000-1AE803FF0000) connected ERROR: Data source 'nrf52840 / nrf52840:device=/dev/ttyACM0' ('nrf52840') encountered an error: did not get a ping response from the capture binary

I also noticed that the nrf_52840.h indicates the incorrect speed of the serial port for nRF Sniffer for Bluetooth LE 4.0.0 must be B1000000 instead of B115200

Or kismet_cap_nrf_52840 created for nRF Sniffer for 802.15.4 firmware ?

[bergeraaron]

kismet_cap_nrf_52840 is for the 802.15.4 firmware as that was the first firmware that I found that would load onto it.

the nrf 51822 was the first one that we had with the BTLE firmware as it was able to get one pre-loaded with firmware.

I have used the BTLE firmware that you have posted there with the 52840 and it should work fine with the kismet_cap_nrf_51822 capture source.

Please try your nrf 52840 with the BTLE firmware with the nrf 51822 capture source and let me know if it doesn't work for you.

[defencore]

I tried nRF52840 firmware: 4.1.0 (recently appeared) & 4.0.0 from nRF Sniffer for Bluetooth LE with kismet_cap_nrf_51822

┌──(u㉿local)-[~/kismet/capture_nrf_51822]
└─$ sudo ./kismet_cap_nrf_51822 --connect 127.0.0.1:3501 --tcp --source=nrf51822:device=/dev/ttyACM0

Not working

I checked the information about nRF52840 & nRF51822 & found next:

• latest nRF Sniffer firmware for nRF51822 was 2.0.0 [info]. I was unable to run this firmware on nRF52840
• there is no nRF Sniffer support for nRF51822 in further firmware 3.0.0 - 4.1.0

[bergeraaron]

Ok, I'll download those newer releases and flash my nrf52840 and test. That is probably newer than the version I had used previously

[bergeraaron]

So I have my nrf52840 flashed with the btle firmware (4.0.0) and am able to use it with the nrf51822 capture source without issue

[1952527.073772] usb 5-4.4.1: new full-speed USB device number 93 using xhci_hcd
[1952527.200531] usb 5-4.4.1: New USB device found, idVendor=1915, idProduct=522a, bcdDevice= 2.03
[1952527.200539] usb 5-4.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1952527.200542] usb 5-4.4.1: Product: nRF Sniffer for Bluetooth LE
[1952527.200544] usb 5-4.4.1: Manufacturer: ZEPHYR
[1952527.200546] usb 5-4.4.1: SerialNumber: BECA110D0D646211
[1952527.249096] cdc_acm 5-4.4.1:1.0: ttyACM0: USB ACM device

bergera@bergera:~/$ kismet_cap_nrf_51822 --connect 127.0.0.1:3501 --tcp --source=nrf51822:device=/dev/ttyACM0
INFO: Connected to '127.0.0.1:3501'...
INFO: 127.0.0.1:3501 starting capture...

INFO: Enabling channel list splitting on sources which share the same list of channels
INFO: Enabling channel list shuffling to optimize overlaps
INFO: Sources will be re-opened if they encounter an error
INFO: Saving datasources to the Kismet database log every 30 seconds.
INFO: Launching remote capture server on 127.0.0.1 3501
INFO: No data sources defined; Kismet will not capture anything until a source is added.
/devices/views/all/last-time/:timestamp/devices
INFO: Opened kismetdb log file './Kismet-20211110-15-12-16-1.kismet'
INFO: Saving packets to the Kismet database log.
INFO: Opened pcapng log file './Kismet-20211110-15-12-16-1.pcapng'
INFO: Starting Kismet web server...
INFO: (DEBUG) Beast server listening on 0.0.0.0:2501
INFO: New remote source nrf51822 (535E0726-0000-0000-0000-00001AE803FF) connected
INFO: Detected new BTLE device CC:50:E3:B5:B7:A6 BLECTF

with the nrf51822 capture source you didn't include what error you are seeing, on both the capture source and the kismet server. Also how quickly it occurs.

Also I'm curious as to what type of system you are running this on?

I can understand the confusion of the capture source naming, but the brtle firmware behaves the same between them. There is a different packet version within it, but that was updated before the release you are using.

[defencore]

Can I ask you to make a full dump of the firmware from your nrf52840 and upload it? Perhaps I am doing something wrong. I have already compile the kismet from the git, re-flashed the nrf52840 and still does not work.

[bergeraaron]

what errors are you getting when you are running it? on the kismet server and on the capture source?

Also which dongle are are you using?

this is the one I have

https://www.mouser.com/ProductDetail/Nordic-Semiconductor/nRF52840-Dongle?qs=gTYE2QTfZfTbdrOaMHWEZg%3D%3D&mgh=1&gclid=Cj0KCQiA-K2MBhC-ARIsAMtLKRvkL5ToU_RAAMBbfCjIybo4y8OY4K96wUa7ipsxVbOGVjFpUpQMh4IaAqsnEALw_wcB

the firmware I am using in the dongle file from the firmware that you had linked to in the initial comments

[defencore]

I'm using this dongle: nRF52840 USB Dongle PA + LNA with nRF Sniffer 4.0.0 firmware

[24732.202162] usb 1-4: new full-speed USB device number 33 using xhci_hcd
[24732.360547] usb 1-4: New USB device found, idVendor=1915, idProduct=522a, bcdDevice= 2.04
[24732.360567] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[24732.360575] usb 1-4: Product: nRF Sniffer for Bluetooth LE
[24732.360581] usb 1-4: Manufacturer: ZEPHYR
[24732.360586] usb 1-4: SerialNumber: A9F59A9D07C288C4
[24732.365732] cdc_acm 1-4:1.0: ttyACM0: USB ACM device

┌──(u㉿local)-[~]
└─$ sudo kismet_cap_nrf_51822 --connect 127.0.0.1:3501 --tcp --source=nrf51822:device=/dev/ttyACM0
INFO: Connected to '127.0.0.1:3501'...
INFO: 127.0.0.1:3501 starting capture...

INFO: Opened kismetdb log file './/Kismet-20211110-23-12-25-1.kismet'
INFO: Saving packets to the Kismet database log.
INFO: Starting Kismet web server...
INFO: (DEBUG) Beast server listening on 0.0.0.0:2501
INFO: New remote source nrf51822 (535E0726-0000-0000-0000-00001AE803FF) connected

if I run a wireshark, then BTLE devices are visible in it

[bergeraaron]

interesting I havent seen that dongle before, looks nice!

what are you using to push it into wireshark?

the firmware reports packets that it sees with no other interaction, IE you dont need to see commands to it for it to sniff, it'll just dump packets on the serial port.

Always possible that the header is a little different or something. I'll look at see where I can have you add some debug prints,etc

[defencore]

I'm using this manual Installing the nRF Sniffer

nRF52840 Dongle (PCA10059)	sniffer_nrf52840donglenrf52840*.hex

[bergeraaron]

If you run kismet and only have this as a datasource does the size of the .kismet file grow? If so would you be willing to send it over?

The packets can be slip encoded, which that data source handles, but there may be something wrong with that or something may have changed. I am unable to reproduce what you are seeing locally with my adapters and that same firmware, so maybe me replaying the .kismet file would help.

[defencore]

*.kismet file size changes very slightly. Same as launching without data sources.

[bergeraaron]

Ok then the packets it is receiving, if it is getting any, are not valid and not getting passed to the next layer. Let me look at what debugging info I can added.

[defencore]

I think the problem is in the serial port reading in capture_nrf_51822.c

[bergeraaron]

That is what I am getting at.

in the following function

/* Run a standard glib mainloop inside the capture thread */
void capture_thread(kis_capture_handler_t *caph) {

it reads from the serial, but since the device is just dumping bytes, it can get partial packets. So it is looking for the header,etc to see if it has a valid packet.

So if you want to see if it is actually getting anything from the serial change the following along line 351 in capture_nrf_51822.c

        valid_pkt = false;
        buf_rx_len = nrf_receive_payload(caph, buf, 256);

        if (buf_rx_len < 0) {
            cf_send_error(caph, 0, errstr);
            cf_handler_spindown(caph);
            break;
        }

to

        valid_pkt = false;
        buf_rx_len = nrf_receive_payload(caph, buf, 256);

        if(buf_rx_len > 0)
        {
                for(int xp=0;xp<buf_rx_len;xp++)
                {
                        printf("%02X",buf[xp];
                }
                printf("\n";
        }

        if (buf_rx_len < 0) {
            cf_send_error(caph, 0, errstr);
            cf_handler_spindown(caph);
            break;
        }

that will print the bytes that it gets back from the serial read, before it tries to see if they are valid or not.

[bergeraaron]

Just wanted to let you know that I was able to replicate the issue, and by putting in the debug printing above I see that my dongle is receiving packets but the format is slightly different, which is why the section of code that looks to see if it is a valid packet is failing.

I should be able to have a PR in to @dragorn in the next day or two.

[bergeraaron]

The fix has been merged into the main branch, so if you pull in the latest from the repo it will work for you with the 51822 capture source.

[defencore]

I tested it. Something started to appear, but not all packets can be parsed. Errors are displayed in the kismet.

[bergeraaron]

Interesting. That will be something that @dragorn will need to look at as I did not run into that issue after running it for an hour.

[bergeraaron]

One thought, you are using it as a remote source is there a specific reason as to why? if you put it as a source in the kismet conf do you still get the same issue?

[kismetwireless]

Try the latest Kismet commit (as of 5 minutes ago); you'll need to rebuild the kismet server part.

-m

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, November 18th, 2021 at 10:54 AM, Aaron Berger @.***> wrote:

One thought, you are using it as a remote source is there a specific reason as to why? if you put it as a source in the kismet conf do you still get the same issue?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[defencore]

Compiled the latest version. Errors no longer appear in the logs, only one device was found nearby, but other devices are not displayed.

[bergeraaron]

another additional update was made last week that should take care of the additional devices not displaying.

[defencore]

I just rebuild a kismet and checked. I already thought that the problem was in the adapter due to the fact that the LNA (Low Noise Amplifier) was disabled, but I switched on different BLE devices near nRF52840 and: Wireshark + extcap - 24 uniq BLE devices per 10 sec Kismet - 1 BLE device per 1 hour

[defencore]

Perhaps this is the reason why I do not see other devices. https://github.com/kismetwireless/kismet/issues/402

I saw my BLE devices in kismet only when they were closer than 5 meters.

[dragorn]

There is absolutely nothing in kismet which would treat proximity any different; if a valid packet arrives from the sniffer, it's handled.

You need to determine if whatever you're seeing in wireshark are valid packets, otherwise it's just noise which has zero meaning.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, December 23rd, 2021 at 4:02 PM, DEFENCORE @.***> wrote:

Perhaps this is the reason why I do not see other devices. #402

I saw my BLE devices in kismet only when they were closer than 5 meters.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.Message ID: @.***>

[defencore]

I can scan with different devices and compare the results.