RPI-3 brmfmac driver - Kernel trace while setting up Ad-hoc mode

[s13884]

I have been trying to setup the Ad-hoc mode using brmfmac but got following logs it crashes while configuring.

[ 161.652031] ------------[ cut here ]------------
[ 161.652121] WARNING: CPU: 3 PID: 97 at net/wireless/ibss.c:67 cfg80211_ibss_joined+0x17c/0x180 [cfg80211]()
[ 161.652130] Modules linked in: joydev brcmfmac evdev brcmutil cfg80211 rfkill snd_bcm2835 snd_pcm snd_timer snd bcm2835_gpi omem bcm2835_rng uio_pdrv_genirq rpi_ft5406 rpi_backlight uio videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common vi deodev media i2c_dev fuse ipv6
[ 161.652243] **CPU: 3 PID: 97 Comm: kworker/3:2 Not tainted 4.1.20-v7+ #867**
[ 161.652252] Hardware name: BCM2709
[ 161.652300] Workqueue: events brcmf_fweh_event_worker [brcmfmac]
[ 161.652338] <800185e0>    (unwind_backtrace)  from  <80013f48>   (show_stack+0x20/0x24)
[ 161.652362] <80013f48>  (show_stack) from <80572ddc>  (dump_stack+0xd4/0x118)
[ 161.652384] <80572ddc>  (dump_stack) from <800271b4>  (warn_slowpath_common+0x98/0xc8)
[ 161.652403] <800271b4>  (warn_slowpath_common) from <800272a0>   (warn_slowpath_null+0x2c/0x34)
[ 161.652472] <800272a0>  (warn_slowpath_null) from <7f1b1f68> (cfg80211_ibss_joined+0x17c/0x180 [cfg80211])
[ 161.652575] <7f1b1f68>  (cfg80211_ibss_joined [cfg80211]) from <7f2f37dc> (brcmf_notify_connect_status+0x284/0x3bc [brcm fmac])
[ 161.652653] <7f2f37dc>  (brcmf_notify_connect_status [brcmfmac]) from <7f2faddc> (brcmf_fweh_call_event_handler+0x48/0xa 4 [brcmfmac])
[ 161.652735] <7f2faddc>  (brcmf_fweh_call_event_handler [brcmfmac]) from <7f2faea0> (brcmf_fweh_event_worker+0x68/0x2d0 [ brcmfmac])
[ 161.652788] <7f2faea0>  (brcmf_fweh_event_worker [brcmfmac]) from <8003e0b8> (process_one_work+0x154/0x458)
[ 161.652811] <8003e0b8>  (process_one_work) from <8003e410> (worker_thread+0x54/0x500)
[ 161.652831] <8003e410>  (worker_thread) from <80043bec> (kthread+0xec/0x104)
[ 161.652851] <80043bec>  (kthread) from <8000faf8>](ret_from_fork+0x14/0x3c)
[ 161.652863] ---[ end trace 5fd34bdc406f077e ]---

Unable to join the ibss. The power management is already off. So anyone ever noticed the same?

[pelwell]

Can you give more information about what you did so we can try to reproduce this?

[s13884]

First disabled the wlan0 from /etc/network/interfaces
#allow-hotplug wlan0
#iface wlan0 inet manual
#wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Command to start the Ad-hoc Mode
iwconfig wlan0 mode ad-hoc essid my-mesh ap 02:CA:FE:FE:FE:40 channel 11

[pelwell]

Thanks for that. I can reproduce the crash on rpi-4.1.y.

What makes you think that this is supposed to work? I'm not sure that it is. You may be better off asking about this on the Raspberry Pi Forums, where people have had success using hostapd: https://www.raspberrypi.org/forums/viewtopic.php?f=36&t=140997&p=940642

[s13884]

Don't you think that is the different part than ad-hoc mode? I think, they are discussing about disable the SSID broadcasting in AP mode. I have already posted my issue on Raspberry Pi forum. https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=142306

I have tested ad-hoc mode on RPI2 using wipi. Please find below the same.
Command to start the ad-hoc mode
sudo iwconfig wlan0 mode ad-hoc essid my-mesh ap 02:CA:FE:FE:FE:40 channel 3
sudo ifconfig wlan0 up

Logs for above commands
[ 111.362520] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 111.363641] wlan0: Created IBSS using preconfigured BSSID 02:ca:fe:fe:fe:40
[ 111.363654] wlan0: Creating new IBSS network, BSSID 02:ca:fe:fe:fe:40
[ 111.401614] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

iw dev wlan0 station dump
connected stations on wlan0
Station XX:XX:XX:01:66:6a (on wlan0)
inactive time: 90 ms
rx bytes: 14139
rx packets: 224
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
signal: -59 dBm
signal avg: -58 dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no
Station XX:XX:XX:ae:5a:1c (on wlan0)
inactive time: 100 ms
rx bytes: 16026
rx packets: 254
tx bytes: 0
tx packets: 0
tx retries: 0
tx failed: 0
signal: -47 dBm
signal avg: -47 dBm
tx bitrate: 1.0 MBit/s
rx bitrate: 1.0 MBit/s
authorized: yes
authenticated: yes
preamble: long
WMM/WME: yes
MFP: no
TDLS peer: no

So I am just trying to do the same thing on RPI3 as iw phy0 info says it supports the ad-hoc IBSS mode.

[s13884]

brcmfmac source has following callback for ibss mode.
.join_ibss = brcmf_cfg80211_join_ibss,
.leave_ibss = brcmf_cfg80211_leave_ibss,

Not sure but some issue with channel as per if (WARN_ON(!channel)) return; at net/wireless/ibss.c:67
Do you think issue with channel?

[s13884]

@pelwell did you get a time to reproduce the crash?

[pelwell]

Nope - not yet.

[s13884]

@pelwell any suggestion to try and check?

[pelwell]

It doesn't crash on 4.4, but it also doesn't work - instead you get:

[  319.461328] brcmfmac: brcmf_cfg80211_change_iface: iface validation failed: err=-16
Error for wireless request "Set Mode" (8B06) :
    SET failed on device wlan0 ; Device or resource busy.

Since we've made our last 4.1 release I'd rather work on the 4.4 tree. To update the kernel and firmware you can use:

sudo rpi-update

[s13884]

Tried 4.4
iw phy0 info says it supports IBSS mode but not in the list of "valid interface combination". It supports AP, Managed and p2p. Is there any chance to support IBSS?

[pelwell]

I'm looking at that next.

[s13884]

Thanks

[pelwell]

I've been slightly diverted into working out why channels 12 & 13 don't work in the 4.6 kernel, but I'll get back to IBSS ASAP.

[pelwell]

IBSS appears to be supported on the 4.5 and 4.6 kernels. I can create an Ad Hoc network, even though I can't do much with it; my Android phone won't connect, and my laptop connects but probably needs some additional networking configuration to be able to make use of it.

I can see the failure 4.4; I don't have a fix yet, but I'm getting closer.

[pelwell]

I've just back-ported two commits to the 4.4 tree that seems to make it work as well as 4.5 for Ad Hoc mode. They will get picked up in the next build.