search

raspberrypi / firmware

This repository contains pre-compiled binaries of the current Raspberry Pi kernel and modules, userspace libraries, and bootloader/GPU firmware.
5.15k stars 1.68k forks source link

Raspberry Pi 2018-04-18 - Cannot put device into adhoc mode #990

Open darkdrgn2k opened 6 years ago

darkdrgn2k commented 6 years ago

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

pelwell commented 6 years ago

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.

darkdrgn2k commented 6 years ago

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.

pelwell commented 6 years ago

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.

darkdrgn2k commented 6 years ago

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

pelwell commented 6 years ago

So the ZeroW thing is just a red herring?

darkdrgn2k commented 6 years ago

Seems like it. Didnt realize there was a new OS dropped last month.

Ill adjust the title

pelwell commented 6 years ago

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.

darkdrgn2k commented 6 years ago

All my test composed of

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)
darkdrgn2k commented 6 years ago

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:~#
darkdrgn2k commented 6 years ago

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

darkdrgn2k commented 6 years ago

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
JamesH65 commented 5 years ago

Any progress on this? Might be worth running the very latest Raspbian as there have been changes in the wireless drivers.

darkdrgn2k commented 5 years ago

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.

ingo-h commented 5 years ago

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.

rikbrown commented 5 years ago

@ingo-h , how can I configure this for the wpa_supplicant that starts on boot?

l-n-s commented 5 years ago

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.

l-n-s commented 5 years ago

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

XECDesign commented 5 years ago

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.

l-n-s commented 5 years ago

@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 wpa_supplicant@.service 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 wpa_supplicant@wlan0.service systemctl enable --now wpa_supplicant@wlan1.service

IMO using wpa_supplicant@.service is less obscure for the end user. It took a while for me to find and disable that hook...

XECDesign commented 5 years ago

Don't wpa_supplicant@.service provide the same feature?

Yes, good point.

A few other reasons I'm not keen on removing the hook right now:

1) 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. 1) 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. 1) 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.

internety commented 5 years ago

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 commented 5 years ago

@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?.

iamdavidcz commented 4 years ago

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

ingo-h commented 3 years ago

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.

RomanJos commented 2 years ago

@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.

JavanXD commented 9 months ago

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