4.19 (linux-next): crash in __cfg80211_disconnected()

[martin-kaiser]

Hi all,

I'm using this driver for an Edimax 7392:7811 with kenrel 4.19 (more precisely: linux-next from 2018-10-19, the latest as of today).

When I am connected to a wireless network and run "ifconfig wlanX down", I see the following crash

wlan0: CTRL-EVENT-DISCONNECTED bs[  165.853683] ------------[ cut here ]------------
sid=36:31:c4:cd:04:19 reason=3 lo[  165.859289] WARNING: CPU: 0 PID: 22 at net/wireless/sme.c:1060 __cfg80211_disconnected+0x70/0x3e4
cally_generated=1
[  165.870905] Modules linked in:
[  165.875567] CPU: 0 PID: 22 Comm: kworker/u2:1 Tainted: G        W         4.19.0-rc8-next-20181019+ #2200
[  165.885339] Hardware name: Freescale i.MX25 (Device Tree Support)
[  165.891550] Workqueue: cfg80211 cfg80211_event_work
[  165.896607] Backtrace:
[  165.899200] [<c000e4c8>] (dump_backtrace) from [<c000e7b0>] (show_stack+0x20/0x24)
[  165.906957]  r6:00000000 r5:c06eb564 r4:00000000 r3:f9a586b3
[  165.912724] [<c000e790>] (show_stack) from [<c0598bc0>] (dump_stack+0x20/0x28)
[  165.920168] [<c0598ba0>] (dump_stack) from [<c001928c>] (__warn+0xec/0x118)
[  165.927424] [<c00191a0>] (__warn) from [<c00193ec>] (warn_slowpath_null+0x4c/0x58)
[  165.935084]  r9:00000000 r8:d307fe84 r7:00000100 r6:c06eb564 r5:00000424 r4:c052f118
[  165.943080] [<c00193a0>] (warn_slowpath_null) from [<c052f118>] (__cfg80211_disconnected+0x70/0x3e4)
[  165.952410]  r6:d307a000 r5:d30ae800 r4:d30891a0
[  165.957223] [<c052f0a8>] (__cfg80211_disconnected) from [<c0503cf8>] (cfg80211_process_wdev_events+0xdc/0x14c)
[  165.967425]  r10:c0813614 r9:00000000 r8:d30ae820 r7:00000100 r6:d30ae880 r5:d30ae800
[  165.975408]  r4:d307fe40
[  165.978037] [<c0503c1c>] (cfg80211_process_wdev_events) from [<c0503ddc>] (cfg80211_process_rdev_events+0x74/0x90)
[  165.988562]  r8:d3817200 r7:d381cc00 r6:00000000 r5:d3089400 r4:d30ae800
[  165.995473] [<c0503d68>] (cfg80211_process_rdev_events) from [<c04fe23c>] (cfg80211_event_work+0x24/0x2c)
[  166.005111]  r5:d30890d4 r4:d30890d4
[  166.008913] [<c04fe218>] (cfg80211_event_work) from [<c002f344>] (process_one_work+0x21c/0x394)
[  166.017800]  r4:d3a318c0 r3:c04fe218
[  166.021488] [<c002f128>] (process_one_work) from [<c003029c>] (worker_thread+0x2f0/0x444)
[  166.029853]  r10:d3817200 r9:c07b0500 r8:d3817214 r7:c07b0500 r6:d3817200 r5:d3a318d4
[  166.037828]  r4:d3a318c0
[  166.040478] [<c002ffac>] (worker_thread) from [<c0034b30>] (kthread+0x110/0x12c)
[  166.048064]  r10:00000000 r9:c002ffac r8:d3a318c0 r7:d3a13298 r6:d38cbe88 r5:d3a21180
[  166.056085]  r4:d3a13280
[  166.058724] [<c0034a20>] (kthread) from [<c00090e0>] (ret_from_fork+0x14/0x34)
[  166.066118] Exception stack(0xd3a5ffb0 to 0xd3a5fff8)
[  166.071242] ffa0:                                     00000000 00000000 00000000 00000000
[  166.079591] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  166.088003] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
[  166.094709]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c0034a20
[  166.102691]  r4:d3a21180 r3:60000053
[  166.106392] ---[ end trace 32acb790bcb78bd7 ]---

This points to

   if (WARN_ON(wdev->iftype != NL80211_IFTYPE_STATION &&                        
          wdev->iftype != NL80211_IFTYPE_P2P_CLIENT))                           

in __cfg80211_disconnected().

It tunerned out that the interface type is "monitor", which was surprising for me.

And in fact, netdev_close() in os_dep/linux/os_intfs.c resets the interface type to monitor when the wireless interface is taken down.

padapter->rtw_wdev->iftype = NL80211_IFTYPE_MONITOR; //set this at the end

Removing the above line fixes the issue for me (as far as I can see). Of course, I'd like to have a proper fix. I hope that someone of you understands the idea behind this part of the code.

The mainline driver for rtl8192cu uses the mac80211 framework and does something similar but it adds a condition

ieee80211_do_stop()
        ...
          if (local->monitors == local->open_count)
               ieee80211_add_virtual_monitor(local);

The corresponding commit message says

commit 4b6f1dd6a6faf4ed8d209bbd548e78b15e55aee8
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Apr 3 14:35:57 2012 +0200

    mac80211: add explicit monitor interface if needed

    The queue mapping redesign that I'm planning to do
    will break pure injection unless we handle monitor
    interfaces explicitly. One possible option would
    be to have the driver tell mac80211 about monitor
    mode queues etc., but that would duplicate the API
    since we already need to have queue assignments
    handled per virtual interface.

    So in order to solve this, have a virtual monitor
    interface that is added whenever all active vifs
    are monitors. We could also use the state of one
    of the monitor interfaces, but managing that would
    be complicated, so allocate separate state.

Can anyone point me in the right direction for fixing the issue properly?

Thanks,
Martin

[klimchuk]

I have the same problem which prevents Raspberry Pi 2 from working as Wi-Fi Access Point
Actually it brings operating system to complete halt
Interested in solution

[hamishmb]

Hi there,

I've recently been trying to use this to make an up to date tutorial for setting these adaptors up on Raspbian (https://www.hamishmb.com/blog/how-to-make-a-raspi-ap-with-a-rtl8xxx-wifi-adaptor/) but I get a kernel panic as soon as anything connects to the AP. Is this a resolved/known issue or anything?

I might well be doing something wrong so if you have any advice please let me know :)

[pvaret]

Hamish, you're probably not doing anything wrong. This driver is just unmaintained. Realtek completely abandoned it, and this repository has now been deprecated for a while. I really wish people would use and help debug the mainline rtl8192cu driver instead (or the rtl8xxxu one if that works better for you). Sometimes I feel that this repo caused more problems than it solved.

[hamishmb]

Hmm, yeah I did see that it was deprecated. Realtek have a lot to answer for, it seems Linux drivers are problematic with a lot of their stuff. The mainline driver doesn't even let me start hostapd sadly :/

[hamishmb]

I hadn't heard of the rtl8xxxu one, that might be worth a look