kismet
kismet copied to clipboard
kismetwireless
Cannot open ubertooth inside Docker
I'm trying to get Ubertooth running inside the kismet docker container. I had added the following to the apt install:
gpsd \ gpsd-clients \ libgps-dev \ librtlsdr-dev \ libbtbb-dev \ libubertooth-dev \ ubertooth \ ubertooth-firmware
Ubertooth-rx runs fine inside the container, but when I try "kismet -c ubertooth", I get the following:
INFO: Found type 'ubertooth' for 'ubertooth' libUSB Error: No such device (it may have been disconnected): (-4) could not open Ubertooth device
I'm running this Docker on a Jetson Nano with it's 18.04 release. Is there an incompatibility?
There's nothing per se that kismet would treat as an incompatibility, but i have no idea how usb performs in docker on arm; you may need to give the container special privileges to unblock its sandboxing.
It could be related to this, too: https://github.com/greatscottgadgets/ubertooth/issues/159
if your version of the firmware doesn't match the version either compiled into kismet (which is the latest for whatever distro you pull the package for, or whatever version you compiled) then that would happen; it could be that your docker repo doesn't have a modern version of the ubertooth libs.
On Wed, Feb 12, 2020 at 12:59 PM Matthew Clark [email protected] wrote:
I'm trying to get Ubertooth running inside the kismet docker container. I had added the following to the apt install:
gpsd
gpsd-clients
libgps-dev
librtlsdr-dev
libbtbb-dev
libubertooth-dev
ubertooth
ubertooth-firmwareUbertooth-rx runs fine inside the container, but when I try "kismet -c ubertooth", I get the following:
INFO: Found type 'ubertooth' for 'ubertooth' libUSB Error: No such device (it may have been disconnected): (-4) could not open Ubertooth device
I'm running this Docker on a Jetson Nano with it's 18.04 release. Is there an incompatibility?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/218?email_source=notifications&email_token=AFKJYY6NBTSLNOMWONGRWPTRCQ2HZA5CNFSM4KT6QTHKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4INARNWA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFKJYYYQANYEXJVOBHWDWALRCQ2HZANCNFSM4KT6QTHA .
I was able to run the ubertooth command directly inside docker and it ran ok. It was only when kismet tried to open the device that I seemed to have problems
Kismet uses libubertooth and hands off all control of the device to that; sorry, I have no idea if they support running in a docker or what you might need to change.
On Thu, Feb 20, 2020 at 2:56 PM Matthew Clark [email protected] wrote:
I was able to run the ubertooth command directly inside docker and it ran ok. It was only when kismet tried to open the device that I seemed to have problems
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/218?email_source=notifications&email_token=AFKJYYYZKBNB4D4GUSFGYJ3RD3N5HA5CNFSM4KT6QTHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMP25QI#issuecomment-589278913, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFKJYY7KNOGGYHYGITVGAO3RD3N5HANCNFSM4KT6QTHA .
So after having to table this for a while, I did some more digging and what's going on is that the USB bus/device of the Ubertooth is being changed (by kismet?) and causes the docker container to get out of sync. For example:
Before enabling ubertooth source:
root@fc0dc4b6107f:/src# lsusb
Bus 002 Device 003: ID 05e3:0626 Genesys Logic, Inc.
Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 009: ID 1d50:6002 OpenMoko, Inc.
Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 012: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
Bus 001 Device 013: ID 2935:0007
Bus 001 Device 011: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 010: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@fc0dc4b6107f:/src# devadm info -q property -n /dev/bus/usb/001/009
bash: devadm: command not found
root@fc0dc4b6107f:/src# udevadm info -q property -n /dev/bus/usb/001/009
BUSNUM=001
DEVNAME=/dev/bus/usb/001/009
DEVNUM=009
DEVPATH=/devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1
DEVTYPE=usb_device
DRIVER=usb
MAJOR=189
MINOR=8
PRODUCT=1d50/6002/106
SUBSYSTEM=usb
TYPE=255/0/0
After enabling the ubertooth:
root@fc0dc4b6107f:/src# lsusb
Bus 002 Device 003: ID 05e3:0626 Genesys Logic, Inc.
Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 014: ID 1d50:6002 OpenMoko, Inc.
Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 012: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter
Bus 001 Device 013: ID 2935:0007
Bus 001 Device 011: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 010: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T
Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@fc0dc4b6107f:/src# udevadm info -q property -n /dev/bus/usb/001/014
device node not found
The container is privileged and I'm going to look for ways to try to force a sync, but my question here is why it's changing at all? I have an Alfa wifi and a number of RTL SDR this doesn't happen with. Does kismet "detach" the Ubertooth somehow?
I didn't think that libubertooth changed any usb modes - the only mode i know of changing is going into dfu - but kismet doesn't do any USB configuration of the ubertooth at all, it exclusively uses the libubertooth API; if something is changing mode, it's required by libubertooth.
On Mon, Oct 26, 2020 at 11:57 AM Matthew Clark [email protected] wrote:
So after having to table this for a while, I did some more digging and what's going on is that the USB bus/device of the Ubertooth is being changed (by kismet?) and causes the docker container to get out of sync. For example:
Before enabling ubertooth source:
root@fc0dc4b6107f:/src# lsusb Bus 002 Device 003: ID 05e3:0626 Genesys Logic, Inc. Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 009: ID 1d50:6002 OpenMoko, Inc. Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 012: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter Bus 001 Device 013: ID 2935:0007 Bus 001 Device 011: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 001 Device 010: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@fc0dc4b6107f:/src# devadm info -q property -n /dev/bus/usb/001/009 bash: devadm: command not found root@fc0dc4b6107f:/src# udevadm info -q property -n /dev/bus/usb/001/009 BUSNUM=001 DEVNAME=/dev/bus/usb/001/009 DEVNUM=009 DEVPATH=/devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1 DEVTYPE=usb_device DRIVER=usb MAJOR=189 MINOR=8 PRODUCT=1d50/6002/106 SUBSYSTEM=usb TYPE=255/0/0
After enabling the ubertooth:
root@fc0dc4b6107f:/src# lsusb Bus 002 Device 003: ID 05e3:0626 Genesys Logic, Inc. Bus 002 Device 002: ID 05e3:0612 Genesys Logic, Inc. Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 014: ID 1d50:6002 OpenMoko, Inc. Bus 001 Device 007: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 008: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 012: ID 0bda:8812 Realtek Semiconductor Corp. RTL8812AU 802.11a/b/g/n/ac WLAN Adapter Bus 001 Device 013: ID 2935:0007 Bus 001 Device 011: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 001 Device 010: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 001 Device 005: ID 05e3:0610 Genesys Logic, Inc. 4-port hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@fc0dc4b6107f:/src# udevadm info -q property -n /dev/bus/usb/001/014 device node not found
The container is privileged and I'm going to look for ways to try to force a sync, but my question here is why it's changing at all? I have an Alfa wifi and a number of RTL SDR this doesn't happen with. Does kismet "detach" the Ubertooth somehow?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/218#issuecomment-716643577, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZAOCETUEI74SHEOWFRDF3SMWL5ZANCNFSM4KT6QTHA .
I figured out the issue. I have to mount /run/udev to the container (despite already running in privileged mode) so it can track the changes in /dev/bus/usb as the Ubertooth is detached/reattached by the kismet capture binary. I saw this while watching udevadm monitor
KERNEL[3649.004502] remove /devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1/1-2.4.1:1.0 (usb)
KERNEL[3649.005838] remove /devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1 (usb)
KERNEL[3649.321243] add /devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1 (usb)
KERNEL[3649.322440] add /devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1/1-2.4.1:1.0 (usb)
and when I checked lsusb over time, the Ubertooth's "Device" was constantly changing:
Bus 001 Device 009: ID 1d50:6002 OpenMoko, Inc.
Bus 001 Device 014: ID 1d50:6002 OpenMoko, Inc.
...
Bus 001 Device 056: ID 1d50:6002 OpenMoko, Inc.
Without mounting /run/udev, the container got a static snapshot of the usb bus/device listing and got out of sync.
Hm, doesn't make much sense to me, but maybe libubertooth does something under the covers. Kismet itself doesn't attach/detach ubertooth devices in any explicit fashion at least.
On Mon, Oct 26, 2020 at 4:32 PM Matthew Clark [email protected] wrote:
I figured out the issue. I have to mount /run/udev to the container (despite already running in privileged mode) so it can track the changes in /dev/bus/usb as the Ubertooth is detached/reattached by the kismet capture binary. I saw this while watching udevadm monitor
KERNEL[3649.004502] remove /devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1/1-2.4.1:1.0 (usb) KERNEL[3649.005838] remove /devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1 (usb) KERNEL[3649.321243] add /devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1 (usb) KERNEL[3649.322440] add /devices/3530000.xhci/usb1/1-2/1-2.4/1-2.4.1/1-2.4.1:1.0 (usb)
and when I checked lsusb over time, the Ubertooth's "Device" was constantly changing:
Bus 001 Device 009: ID 1d50:6002 OpenMoko, Inc. Bus 001 Device 014: ID 1d50:6002 OpenMoko, Inc. ... Bus 001 Device 056: ID 1d50:6002 OpenMoko, Inc.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kismetwireless/kismet/issues/218#issuecomment-716806086, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZAOCG6P4SSBRWRK2SRBGLSMXMHHANCNFSM4KT6QTHA .