firmware
firmware copied to clipboard
raspberrypi
Raspberry Pi 2018-04-18 - Cannot put device into adhoc mode
Cant seem to put the onboard wifi into AdHoc mode
pi@rpizero1:~ $ set -e
pi@rpizero1:~ $ sudo iw reg set CA
pi@rpizero1:~ $ mesh_dev="wlan0"
pi@rpizero1:~ $ sudo ifconfig $mesh_dev down
pi@rpizero1:~ $ sudo iw $mesh_dev set type ibss
command failed: Device or resource busy (-16)
dmesg shows
brcmfmac: brcmf_cfg80211_change_iface: iface validation failed: err=-16
Update
2018-04-18-raspbian-stretch-lite.img does not work 2018-03-13-raspbian-stretch-lite.img works fine
Seems to only be the raspberry pi zero.
What makes you say this? I couldn't get this sequence of commands to work on a 3B+, and I don't expect a Pi 3 to be any different.
From what I can see, this isn't the way to start ad hoc mode - instead, try following the first answer in this stackexchange thread: https://raspberrypi.stackexchange.com/questions/49660/ad-hoc-setup-in-rpi-3 You will also need to run "sudo systemctrl disable dhcpcd" before rebooting.
If that works for you then you may be able to find a more modern, dhcpcd-friendly way to achieve the same end, but until then you have a workaround.
I am able to put a RPI3B into adhoc mode with no problem
pi@tomesh-a0b8:~ $ sudo iw reg set CA
pi@tomesh-a0b8:~ $ mesh_dev="wlan0"
pi@tomesh-a0b8:~ $ sudo ifconfig $mesh_dev down
pi@tomesh-a0b8:~ $ sudo iw $mesh_dev set type ibss
pi@tomesh-a0b8:~ $ sudo iw dev $mesh_dev ibss join MESH_NAME 2412
pi@tomesh-a0b8:~ $ sudo ifconfig $mesh_dev up
pi@tomesh-a0b8:~ $ iw dev
phy#0
Interface wlan0
ifindex 3
wdev 0x1
addr b8:27:eb:00:00:00
ssid MESH_NAME
type IBSS
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 31.00 dBm
Pi3b+ and Pi 3b WiFi are different chip Pi3b is 2.4 Ghz while PI3b+ is a dual band 5ghz chip. Not sure why you would expect them to work the same.
In fact we are having a bunch of random issues with the pi3b+. For example not being able to NAT ipv6 to a fc00/8 network when we use the the onboard wireless as an access point (see issue) but works perfectly fine on a PI3b or when a usb dongle is used for the AP.
My 3B fails in exactly the same way as the Zero W (and the 3B+, which is obviously a different but related chip).
Are you using the same uSD card when testing ZeroW and 3B?
If you have problems with the 3B+ that manifest as driver problems then report them here, one Issue per problem.
If you have problems with the 3B+ that manifest as driver problems then report them here, one Issue per problem.
I'm trying to rule out all other issues before posting here, thank you.
Are you using the same uSD card when testing ZeroW and 3B?
No it is not. However i have had several people get ISBB working successfully and for several days now. Our project just implemented AdHoc as an option since MeshPoint (80211s) is not supported on the chipsets.
I did some testing with an unopened a brand new pi 3b v1.2 (out of the box) and the 3bv1.2 that worked
here is what i found
2018-04-18-raspbian-stretch-lite.img does not allow me to enter IBSS on either board 2018-03-13-raspbian-stretch-lite.img works fine
Possbly an issue with the latest version of Raspberry PI os
Seems like it. Didnt realize there was a new OS dropped last month.
Ill adjust the title
A clean installation of 2018-03-13 Raspbian Stretch shows the same behaviour, as does 2017-22-29 Stretch (Full and Lite). 2018-03-13 Raspbian Stretch Lite returns error -19 instead (-ENODEV), but that could be as a result of finger trouble.
It seems to me that you must have some performed some other configuration on the image where it works. Unless you produce a clear sequence of steps to get from a clean image to a state where "set type ibss" works there's nothing I can do.
All my test composed of
- Using 2018-03-13-raspbian-stretch-lite.img
- Flashed with Win32 Disk Imager - 1.0
- 8GB d card
- Once flashed folder "ssh" was created and placed in the PI
- Once pi booted SSH over Ethernet is established and the following commands are run one by one
sudo iw reg set CA
mesh_dev="wlan0"
sudo ifconfig $mesh_dev down
sudo iw $mesh_dev set type ibss
sudo iw dev $mesh_dev ibss join MESH_NAME 2412
sudo ifconfig $mesh_dev up
iw dev
No other configuration. When I tested yesterday I was very careful to follow the steps above.
Today however it is not working again on any board. I continue testing but this is perplexing
Debug shows
-- Debug: Sent Message:
-------------------------- BEGIN NETLINK MESSAGE ---------------------------
[NETLINK HEADER] 16 octets
.nlmsg_len = 36
.type = 22 <0x16>
.flags = 5 <REQUEST,ACK>
.seq = 1525875462
.port = 2139095687
[GENERIC NETLINK HEADER] 4 octets
.cmd = 6
.version = 0
.unused = 0
[PAYLOAD] 16 octets
08 00 03 00 03 00 00 00 08 00 05 00 01 00 00 00 ................
--------------------------- END NETLINK MESSAGE ---------------------------
-- Debug: Received Message:
-------------------------- BEGIN NETLINK MESSAGE ---------------------------
[NETLINK HEADER] 16 octets
.nlmsg_len = 56
.type = 2 <ERROR>
.flags = 0 <>
.seq = 1525875462
.port = 2139095687
[ERRORMSG] 20 octets
.error = -16 "Device or resource busy"
[ORIGINAL MESSAGE] 16 octets
.nlmsg_len = 16
.type = 22 <0x16>
.flags = 5 <REQUEST,ACK>
.seq = 1525875462
.port = 2139095687
--------------------------- END NETLINK MESSAGE ---------------------------
command failed: Device or resource busy (-16)
Ok i thought i was going crazy. As every time i tried it today it did not work
I decided to try our small ram disk debian os that runs bare bones (currently does not support RPI3B+ .. something about repos not being correctly updated. not use) https://github.com/benhylau/mesh-router-builder/releases/download/v0.8/raspberrypi3-0.8_default.img
Anyway it worked first try
root@ramdisk-581d8ee2:~# iw reg set CA
root@ramdisk-581d8ee2:~# mesh_dev="wlan0"
root@ramdisk-581d8ee2:~# iw $mesh_dev set type ibss
root@ramdisk-581d8ee2:~# iw dev $mesh_dev ibss join MESH_NAME 2412
root@ramdisk-581d8ee2:~# iw dev
phy#0
Interface wlan0
ifindex 3
wdev 0x1
addr b8:27:eb:0a:5a:69
ssid MESH_NAME
type IBSS
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 31.00 dBm
root@ramdisk-581d8ee2:~#
The plot thickens.
Powered up Raspbian again (again clean install no other configs except ssh in boot partition)
Looking around for possible issues i decided to do
service networking stop
After that IBSS enabled no problem.
I rebooted and tried to re-create the solution and it failed again with same error
Test script
sudo iw reg set CA
mesh_dev="wlan0"
sudo ifconfig $mesh_dev down
sudo iw $mesh_dev set type ibss
sudo ifconfig $mesh_dev up
sudo iw dev $mesh_dev ibss join tomesh 2412
iw dev
Raspberry Pi 3B+
Stock Raspbian (2018-06-27-raspbian-stretch-lite.img) worked without a problem
phy#0
Interface wlan0
ifindex 3
wdev 0x1
addr b8:27:eb:13:76:3a
ssid tomesh
type IBSS
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 31.00 dBm
Raspberry Pi 3B
Stock Raspbian (2018-06-27-raspbian-stretch-lite.img) did not work
Error command failed: Device or resource busy (-16) on IBSS JOIN
Stock Raspbian (2017-01-11-raspbian-jessie.img) comes up with no error. However does not seem to join correctly (no stations detected)
iw dev does not show frequency
Interface wlan0
ifindex 3
wdev 0x1
addr b8:27:eb:29:e0:5d
ssid tomesh
type IBSS
Stock Raspbian (2017-06-21-raspbian-jessie-lite.img) comes up with no error. However stilll does not seem to join correctly (no stations detected).
iw dev show frequency now but not strength
Interface wlan0
ifindex 3
wdev 0x1
addr b8:27:eb:29:e0:5d
ssid tomesh
type IBSS
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
Any progress on this? Might be worth running the very latest Raspbian as there have been changes in the wireless drivers.
Yes i got it to work
So far 3b+ seemed to have worked but 3b did not.
After some poking I got 3b working by killing wpa_supplicant process first.
For me this error occurs to be a problem with the background driver nl80211. Just for testing I use an empty /etc/wpa_supplicant/wpa_supplicant.conf:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
Then start wpa_supplicant:
pi@raspberrypi:~ $ sudo /sbin/wpa_supplicant -Dnl80211 -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf -B
Successfully initialized wpa_supplicant
pi@raspberrypi:~ $ iw dev
phy#0
Unnamed/non-netdev interface
wdev 0x6
addr ee:45:87:00:ad:54
type P2P-device
txpower 31.00 dBm
Interface wlan0
ifindex 3
wdev 0x1
addr b8:27:eb:06:e8:8b
type managed
channel 34 (5170 MHz), width: 20 MHz, center1: 5170 MHz
txpower 31.00 dBm
pi@raspberrypi:~ $
I don't know what this P2P-device with an Unnamed/non-netdev interface is. For me it looks buggy. Obviously it prevents to set type IBSS.
pi@raspberrypi:~ $ sudo iw wlan0 set type ibss
command failed: Device or resource busy (-16)
pi@raspberrypi:~ $
To verify this I just used the old background driver wext:
pi@raspberrypi:~ $ sudo killall wpa_supplicant
pi@raspberrypi:~ $ sudo /sbin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf -B
Successfully initialized wpa_supplicant
ioctl[SIOCSIWENCODEEXT]: Invalid argument
ioctl[SIOCSIWENCODEEXT]: Invalid argument
pi@raspberrypi:~ $ sudo iw wlan0 set type ibss
pi@raspberrypi:~ $ iw dev
phy#0
Interface wlan0
ifindex 3
wdev 0x1
addr b8:27:eb:06:e8:8b
type IBSS
channel 34 (5170 MHz), width: 20 MHz, center1: 5170 MHz
txpower 31.00 dBm
pi@raspberrypi:~ $
I can confirm that unprotected ad-hoc communication also works. So if you are comfortable with the old background driver wext then it is a workaround for this issue.
@ingo-h , how can I configure this for the wpa_supplicant that starts on boot?
I've stumbled upon this issue right now.
It seems like Raspbian starts wpa_supplicant somehow for wlan0, and it can't be disabled with systemctl. If you kill all wpa_supplicant processes manually (like with killall wpa_supplicant) the IBSS mode starts working just fine.
The actual problem here is with nl80211 driver which wpa_supplicant uses.
So, that unwanted wpa_supplicant process is spawned by dhcpcd.service hook script for wpa_supplicant. Probably there is a bug in that hook script, because it should not start wpa_supplicant if wpa_supplicant.service is disabled.
The quick and dirty way to disable that buggy hook is just to do:
sudo killall wpa_supplicant
sudo rm /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant
OR you can just systemctl disable dhcpcd.service
Probably there is a bug in that hook script, because it should not start wpa_supplicant if wpa_supplicant.service is disabled.
Originally, wpa_supplicant didn't have a service tos tart it, so the hook was required. The hook offers some flexibility - like per-interface configuration files. I think the next image will ship with the service disabled and rely on the hook instead.
@XECDesign right, my mistake. The hook is not buggy, it does what it says it does.
The hook offers some flexibility - like per-interface configuration files
Don't [email protected] provide the same feature? On my laptop I have the following config files:
/etc/wpa_supplicant/wpa_supplicant-wlan0.conf
/etc/wpa_supplicant/wpa_supplicant-wlan1.conf
and they can be started by doing:
systemctl enable --now [email protected]
systemctl enable --now [email protected]
IMO using [email protected] is less obscure for the end user. It took a while for me to find and disable that hook...
Don't
[email protected]provide the same feature?
Yes, good point.
A few other reasons I'm not keen on removing the hook right now:
- The way it's started by the service doesn't work with wpa_cli, the desktop applet and it doesn't use /etc/wpa_supplicant/wpa_supplicant.conf. I don't understand how it's meant to work without something else to talk to it.
- I remember adding -Dnl80211,wext to the hook, but I'm not 100% sure what for. I believe there's a commonly used wifi dongle that doesn't work without that.
- The hook has been in use for years. Removing it now is likely to result in a flood of "my wifi is broken" posts, which happens every single time the network setup is touched in any way.
sudo rm /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant
is better to make the changes undo-able. why not to use nohook directive in dhcpcd.conf?
@ingo-h , how can I configure this for the wpa_supplicant that starts on boot?
@rikbrown Sorry for the late answer. I have made a setup on a Raspberry Pi. You can look at How to setup an unprotected Ad Hoc (IBSS) Network and if possible with WPA encryption?.
I have encountered the similar brcmfmac error message in dmesg when running iwd on the Raspberry Pi 4 on the following kernel:
$ uname -a
Linux rpi.localdomain 5.4.51-v7l+ #1330 SMP Thu Jul 30 10:34:05 BST 2020 armv7l BCM2711 GNU/Linux
dmesg:
[ 244.208903] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 244.222027] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar 23 2020 02:19:54 version 7.45.206 (r725000 CY) FWID 01-88ee44ea
[ 244.231692] ieee80211 phy0: brcmf_cfg80211_add_iface: iface validation failed: err=-16
[ 244.285781] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
I have also tried the older brcmfmac driver, but it still shows the same error in dmesg...
EDIT: There are similar cases that can be easily found over the Internet: https://archlinuxarm.org/forum/viewtopic.php?t=12340 https://lists.opensuse.org/opensuse-arm/2017-08/msg00042.html
As noted in my https://github.com/raspberrypi/firmware/issues/990#issuecomment-462162662 I could not set the interface to type IBSS (ad-hoc).
pi@raspberrypi:~ $ sudo iw wlan0 set type ibss
command failed: Device or resource busy (-16)
pi@raspberrypi:~ $
I have found the reason. Wpa_supplicant starts by default with p2p enabled that is used for WiFi-Direct. As noted in /usr/share/doc/wpa_supplicant/examples/wpa_supplicant.conf this is
# mode: IEEE 802.11 operation mode
# 0 = infrastructure (Managed) mode, i.e., associate with an AP (default)
# 1 = IBSS (ad-hoc, peer-to-peer)
# 2 = AP (access point)
mode=1 is used for ad-hoc AND peer-to-peer so the Device or resource is busy on startup. To avoid this you have to set option
p2p_disabled=1
in /etc/wpa_supplicant/wpa_supplicant.conf. This will prevent running p2p on startup and you are able to set IBSS (ad-hoc) on the interface.
@ingo-h I can't express how grateful I am.
Using buildroot, I originally didn't build wpa_supplicant with AP mode so the p2p_disabled option from your post had no use for me. I now need the AP capabilities and couldn't understand why the build option alone was doing this !
Thank you so much.
I faced the same issue, my existing script worked for all Raspbian Systems on all Raspberry Pi's. I was able to create both an AP and connect to an WiFi at the same time, on some Raspberrys this needed some tweakings, as I had to create the AP on the same channel as the WiFi. My project is used by hundreds of people deployed on all possible Raspberrys.
But after migrating my pi-gen script to the latest bullseye Raspberry OS release I also got this error.
I found this Stackoverflow article describing the issue and providing a working workaround: https://raspberrypi.stackexchange.com/a/133197
So the final resolution for me was that by default dhcpcd (the DHCP client daemon) launches wpa_supplicant on every interface it discovers using a hook (/usr/share/dhcpcd/hooks/10-wpa_supplicant). This results in a conflict where hostapd wants to run the interface in AP mode and wpa_supplicant probably wants it in station mode. The solution is to disable the hook in the dhcpcd config file /etc/dhcpcd.conf by adding
interface ap0 # interface used by hostapd
nohook wpa_supplicant
