I am trying to enable monitoring mode for a USB wifi dongle with the RTL8188CUS chipset on a raspberry pi model b+ (or any raspberry pi for that matter).
$ lsusb
Bus 001 Device 005: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter
$ sudo iwconfig wlan0 mode monitor
Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Invalid argument.
According to github/raspberrypi/linux/issues/369, you need to enable the rtlwifi/rtl8192cu kernel module that is included with the kernel distribution but not compiled. This requires minor modifications to some files as diff'ed below in 'STEP 2'.
The USB issue mentioned in that thread has been resolved as of 4.1.6+, so the rtlwifi driver should work.
Steps to recreate on a fresh raspberry pi (model B+)...
STEP 0: Update existing modules and kernel to latest
$ sudo apt-get update
$ sudo rpi-update
$ uname -a
Linux raspberrypi 4.1.7+ #815 PREEMPT Thu Sep 17 17:59:24 BST 2015 armv6l GNU/Linux
STEP 1: Get the raspbian kernel source and add missing dependencies
$ git clone --depth=1 https://github.com/raspberrypi/linux
$ sudo apt-get install bc lshw
STEP 2: Enable the rtlwifi (kernel) drivers for RTL8188CUS (RTL8192)
edit linux/drivers/net/wireless/Kconfig
-#source "drivers/net/wireless/rtlwifi/Kconfig"
-source "drivers/net/wireless/rtl8192cu/Kconfig"
+source "drivers/net/wireless/rtlwifi/Kconfig"
+#source "drivers/net/wireless/rtl8192cu/Kconfig"
(Wheezy) edit linux/drivers/net/wireless/Makefile
-#obj-$(CONFIG_RTLWIFI) += rtlwifi/
+obj-$(CONFIG_RTLWIFI) += rtlwifi/
(Jessie) edit linux/drivers/net/wireless/realtek/Makefile
-#obj-$(CONFIG_RTLWIFI) += rtlwifi/
+obj-$(CONFIG_RTLWIFI) += rtlwifi/
STEP 3: Compile and install kernel (took many hours)
Summarized from kernel building documentation .
$ cd linux
$ KERNEL=kernel
$ make bcmrpi_defconfig
$ make zImage modules dtbs
$ sudo make modules_install
$ sudo cp arch/arm/boot/dts/*.dtb /boot/
$ sudo cp arch/arm/boot/dts/overlays/*.dtb* /boot/overlays/
$ sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
$ sudo scripts/mkknlimg arch/arm/boot/zImage /boot/$KERNEL.img
STEP 4: Reboot
$ sudo reboot
STEP 5: Check that the rtlwifi/rtl8192cu module is loaded
$ lsmod | fgrep rtl8192cu
rtl8192cu 100806 0
rtl_usb 14781 1 rtl8192cu
rtl8192c_common 72091 1 rtl8192cu
rtlwifi 101122 3 rtl_usb,rtl8192c_common,rtl8192cu
mac80211 623281 3 rtl_usb,rtlwifi,rtl8192cu
$
$ lshw
*-network:0
description: Ethernet interface
physical id: 1
bus info: usb#1:1.3
logical name: wlan0
serial: 00:0b:81:94:e9:a3
capabilities: ethernet physical
configuration: broadcast=yes driver=rtl8192cu driverversion=4.1.7+ firmware=N/A link=no multicast=yes
STEP 6: Try to activate monitoring mode
$ sudo iwconfig wlan0 mode monitor
Error for wireless request "Set Mode" (8B06) :
SET failed on device wlan0 ; Operation not supported.
What did i miss?
Issue 369 seems to indicate that it can work with the rtlwifi driver?
Turns out the steps to recompile and load the rtlwifi module are correct. The problem is iwconfig not working to enable/determine monitoring mode in this situation.
Instead, I used iw as outlined by Steven Gordon - Capturing WiFi in Monitor mode with iw and it worked.
To summarize:
STEP 6b: List the physical network interfaces available
$ iw dev
STEP 7: Determine if the physical interface supports monitoring mode
$ iw phy phy0 info
... lots of stuff ...
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor
* mesh point
* P2P-client
* P2P-GO
... lots more stuff ...
STEP 8: Add a monitoring interface to that physical card
You need to explicitly add a 'monitoring' interface for the hardware you have.
$ sudo iw phy phy0 interface add mon0 type monitor
STEP 8: Start monitoring
In my case, I'm using tshark to facilitate monitoring, displaying a few useful fields rather than a lot of noise.
$ sudo apt-get install tshark
$ sudo tshark -i mon0 -f 'broadcast' -T fields -e frame.time_epoch -e wlan.sa -e radiotap.dbm_antsignal -e wlan.fc.type -e wlan.fc.subtype
Done.
For anyone still interested, the rtl8192cu is now compiled into the raspberry kernel by default. It can be activated by commenting out the blacklist in /etc/modprobe.d/blacklist-rtl8192cu.conf. Executing sudo iwconfig wlan0 mode monitor after a reboot will activate monitoring mode without any further problems.
Related
I have a pci address for a device, and need to find the pci address of its hostbridge. In FreeBSD 11 it is very easy to do that using "devinfo -v" as you can grep the pci address of the device and then you can find its parent in the tree which is the hostbridge. Now in FreeBSD 10 there is no any pci address in the output of the "devinfo -v". Example of "devinfo -v" output in FreeBSD 11:
pcib4 pnpinfo vendor=0x8086 device=0x2f08 subvendor=0x15d9 subdevice=0x0833 class=0x060400 at pci0:0:3:0 handle=\_SB_.PCI0.BR3A
pci4
mlx5_core1 pnpinfo vendor=0x15b3 device=0x1013 subvendor=0x15b3 subdevice=0x0010 class=0x020700 at pci0:3:0:0 handle=\_SB_.PCI0.BR3A.H000
mlx5_core2 pnpinfo vendor=0x15b3 device=0x1013 subvendor=0x15b3 subdevice=0x0010 class=0x020700 at pci0:3:0:1 handle=\_SB_.PCI0.BR3A.H001
Example of "devinfo -v" output in FreeBSD 10:
pcib4 pnpinfo vendor=0x8086 device=0x2f08 subvendor=0x15d9 subdevice=0x0833 class=0x060400
pci4
mlx5_core1 pnpinfo vendor=0x15b3 device=0x1013 subvendor=0x15b3 subdevice=0x0010 class=0x020700
mlx5_core2 pnpinfo vendor=0x15b3 device=0x1013 subvendor=0x15b3 subdevice=0x0010 class=0x020700
So You can see that the pci addresses are not appearing in output of FreeBSD10
There is 2-step workaround. At first find device name:
pciconf -l -v | grep "pci0:2:0:0" | cut -f 1 -d #
In my case it's sdhci_pci0.
Then find location in devinfo:
$ devinfo | grep -B 5 sdhci_pci0
pcm2
pcm3
pcm4
pcib1
pci2
sdhci_pci0
Note:
On FreeBSD10.2-STABLE I can see PCI info in output of devinfo.
Another possibility is to walk through the dev sysctl tree:
You can grep for the PCI address you have in the %location OID:
$ sysctl dev | grep %location
dev.hdac.1.%location: pci0:0:27:0 handle=\_SB_.PCI0.HDEF
dev.hdac.0.%location: pci0:2:0:1
dev.vgapci.0.%location: pci0:2:0:0 handle=\_SB_.PCI0.PEG3.MXM3
dev.hostb.15.%location: pci0:255:5:3
dev.hostb.14.%location: pci0:255:5:2
You can then find the parent using the %parent OID. For instance, the parent of pci0:2:0:0 (listed in the example above) is pci1:
$ sysctl dev.vgapci.0.%parent
dev.vgapci.0.%parent: pci1
The parent has its own sysctl tree:
$ sysctl dev.pcib.1.%location
dev.pcib.1.%location: pci0:0:3:0 handle=\_SB_.PCI0.PEG3
Not the most straightforward approach, but it should work accross different versions of FreeBSD (and probably DragonFlyBSD FWIW).
Try devinfo -rv.
A snippet of output on FreeBSD 10.3:
atapci1 pnpinfo vendor=0x8086 device=0x27c0 subvendor=0x1043 subdevice=0x8179 class=0x01018f at p
ci0:0:31:2 handle=\_SB_.PCI0.IDE1
Interrupt request lines:
0x13
I/O ports:
0xb880-0xb88f
0xbc00-0xbc03
0xc000-0xc007
0xc080-0xc083
0xc400-0xc407
ata2 at channel=0
ata3 at channel=1
I work on embedded device and I am configuring the WLAN module (QCA6174 - ath10k driver) with wpa_supplicant.
I load the driver modules (backports-20151120):
insmod /lib/modules/3.10.65-b2196-h301/wlan/compat.ko;
insmod lib/modules/3.10.65-b2196-h301/wlan/cfg80211.ko;
insmod /lib/modules/3.10.65-b2196-h301/wlan/mac80211.ko;
insmod /lib/modules/3.10.65-b2196-h301/wlan/ath.ko;
insmod /lib/modules/3.10.65-b2196-h301/wlan/ath10k_core.ko skip_otp=y;
insmod /lib/modules/3.10.65-b2196-h301/wlan/ath10k_pci.ko
I start the wpa_supplicant (default wpa_supplicant.conf):
wpa_supplicant -dd -Dwext -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf -B
[ 182.257304] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
everything seems to work fine. I see the wlan0 interface,I can scan with iwlist, /var/run/wpa_supplicant/wlan0 exist.
But I can not use wpa_cli interface:
#wpa_cli
wpa_cli v2.4
Copyright (c) 2004-2015, Jouni Malinen <j#w1.fi> and contributors
Selected interface 'wlan0'
Interactive mode
Could not connect to wpa_supplicant: wlan0 - re-trying
Do you have any hints how can I track down the problem ?
After issuing
strace wpa_cli -i wlan0
the problem with /tmp folder was reported:
bind(3, {sa_family=AF_FILE, path="/tmp/wpa_ctrl_1095-5"}, 110) = -1 EROFS (Read-only file system)
After mounting tmpfs:
mount -t tmpfs -o size=12m tmpfs /tmp/
everything works fine.
I solved this by running sudo wpa_cli -i wlan0 in response to the "Read-only file system" permissions error.
In contrast to the accepted answer, this does not carry the side-effect of altering the permissions of the directory mounted at /tmp/.
Thank you #BartlomiejGrzeskowiak. I did not know about strace.
Getting status of serial ports (ttyS*) via linux terminal is simple:
sudo cat /proc/tty/driver/serial
Then it shows serinfo with list of all uarts with info about status and buffers. When I call
sudo cat /proc/tty/drivers
then I can see that rfcomm drivers are available:
rfcomm /dev/rfcomm 216 0-255 serial
And, of course, reading data comming from paired bluetooth device is not a problem.
The question is: how to get status of rfcomm serial ports (e.g. Blueotooth SPP devices)? Is this information available somewhere in the /proc directory like for ttyS* or could I use totally different way?
It depends what status you are looking for. The "rfcomm" command that comes with bluez does have some status info. It depends if that is adequate for you.
% rfcomm -h
RFCOMM configuration utility ver 4.101
Usage:
rfcomm [options] <command> <dev>
Options:
-i [hciX|bdaddr] Local HCI device or BD Address
-h, --help Display help
-r, --raw Switch TTY into raw mode
-A, --auth Enable authentication
-E, --encrypt Enable encryption
-S, --secure Secure connection
-M, --master Become the master of a piconet
-f, --config [file] Specify alternate config file
-a Show all devices (default)
Commands:
bind <dev> <bdaddr> [channel] Bind device
release <dev> Release device
show <dev> Show device
connect <dev> <bdaddr> [channel] Connect device
listen <dev> [channel [cmd]] Listen
watch <dev> [channel [cmd]] Watch
Attempt to run the following command with root privilege on kernel 2.6.35 results in error:
% echo 0000:00:03.0 > /sys/bus/pci/drivers/foo/bind
-bash: echo: write error: No such device
UPDATE
The device does exist in /sys/bus/pci/devices/ the output of lspci is as follows:
% lspci -v -s 0000:00:03.0
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)
Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10
Memory at f0000000 (32-bit, non-prefetchable) [size=128K]
I/O ports at d010 [size=8]
Capabilities: <access denied>
Kernel driver in use: e1000
I think I resolved the issue. It appears that the driver requires to unbind device at first.
It also appears that the shell processes redirection (echo .. > /sys/bus/..) with user permission, and 'sudo' handles only the command, i.e. 'echo' but not the whole command line that follows it, therefore it has to be executed this way:
% sudo sh -c "echo 0000:00:03.0 > /sys/bus/pci/drivers/foo/unbind"
% sudo sh -c "echo 0000:00:03.0 > /sys/bus/pci/drivers/foo_new/bind"
I need to deal with two pieces of custom hardware which both send debugging data over two serial connections. Those serial connections go through two serial-to-USB converters. The serial-to-USB devices have the same vendor numbers, device numbers, and, apparently, the same serial numbers.
Here's the issue: I want to log the two serial ports separately. The custom hardware needs to be rebooted constantly, and whether they attach to the same /dev/ttyUSB* is completely random. How can I make them pick the same device path every time? I could make it dependent on what port it is plugged into, but that seems kind of hacky.
So, I ran a diff against the output of udevadm, like so:
$ udevadm info -a -p `udevadm info -q path -n /dev/ttyUSB1` > usb1
$ udevadm info -a -p `udevadm info -q path -n /dev/ttyUSB2` > usb2
$ diff usb1 usb2
The output of the diff is long; you can see it here
Grepping for serial (same for both):
$ udevadm info -a -p `udevadm info -q path -n /dev/ttyUSB2` | grep serial
SUBSYSTEMS=="usb-serial"
ATTRS{serial}=="0001"
ATTRS{serial}=="0000:00:1d.7"
Other info:
I'm using PuTTY to read from the serial ports.
OS:
$ uname -a
Linux xxxxxxxx.localdomain 2.6.32-279.14.1.el6.x86_64 #1 SMP Tue Nov 6 23:43:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Please check if the usb-serial converter is based on a ftdi chip?
(You can check driver filenames)
If so; you have a chance to change serial number,or even the manufacturer info.
http://www.ftdichip.com/Support/Utilities.htm
Check the tools; MProg and FT_PROG utility tools.