* rtw88 strange killall behaviour with nm
@ 2021-04-20 1:02 Madhu
2021-04-20 4:34 ` Klaus Müller
0 siblings, 1 reply; 5+ messages in thread
From: Madhu @ 2021-04-20 1:02 UTC (permalink / raw)
To: linux-wireless
I was using the rtw88 on (lspci: Realtek. RTL8822CE 802.11ac PCIe on a
Lenovo Thinkbook) fairly normally on gentoo (kernel 5.10.30) with
netifrc scripts. Recently I tried to move the scripts to
networkmanager connection files.
1. With NM the WPA-PSK connection to my AP (dlink router - india)
keeps dropping (citing a CLASS2_FRAME_FROM_NONAUTH_STA error)
2. With a specific connection file - if I activate the connection with
nmcli conn activate the kernel apparently terminates all processes on
the system except the NetworkManager process. (For added fun this
crashes the drm video + keyboard if Xorg is running requiring a
powercycle)
How could this behaviour (all tasks being terminated) possibly happen?
Is it b related specifically to the rtw88 module? Have you heard of
anything like this before?
[Other Issues I had were
3. occasional RIPs "purge skb(s) not reported by firmware"
4. RIPs when I try to run kismet which may be related to:
5. Usually I see only 2-3 APs from this card on linux. On a b43 driver
older laptop I can usually see 10-15 APs at the same time. I suspect
the kismet RIPS happen when processing these other APs
]
In any case I'm intrigued by the (2) kernel repeatably killing off all
my processes when nmcli fires up. This is a bit hard to debug as
there is nothing helpful in dmesg afaict. (and syslog exits early)
How is this even possible. (Offhand I can't spot where nm is calling
killall)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: rtw88 strange killall behaviour with nm
2021-04-20 1:02 rtw88 strange killall behaviour with nm Madhu
@ 2021-04-20 4:34 ` Klaus Müller
2021-04-21 4:51 ` Madhu
0 siblings, 1 reply; 5+ messages in thread
From: Klaus Müller @ 2021-04-20 4:34 UTC (permalink / raw)
To: linux-wireless
On 20.04.21 at 03:02 Madhu wrote:
>
> I was using the rtw88 on (lspci: Realtek. RTL8822CE 802.11ac PCIe on a
> Lenovo Thinkbook) fairly normally on gentoo (kernel 5.10.30) with
> netifrc scripts. Recently I tried to move the scripts to
> networkmanager connection files.
Did you try https://github.com/lwfinger/rtw88
Thanks
Klaus
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: rtw88 strange killall behaviour with nm
2021-04-20 4:34 ` Klaus Müller
@ 2021-04-21 4:51 ` Madhu
2021-09-11 22:09 ` help troubleshooting failures connect to an access point with iw/iwd Madhu
0 siblings, 1 reply; 5+ messages in thread
From: Madhu @ 2021-04-21 4:51 UTC (permalink / raw)
To: linux-wireless
* Klaus Müller <9167fd6d-affa-21d5-bd8d-0fb3d49d38f0@justmail.de> :
Wrote on Tue, 20 Apr 2021 06:34:56 +0200:
> Did you try https://github.com/lwfinger/rtw88
Yes, after the first time it happened (with the stock 5.10.30 kernel)
I updated the rtw88 firmware from git, it happened again. Then i used
the modules from the above location (which also match the git
firmware), and the behaviour persists.
^ permalink raw reply [flat|nested] 5+ messages in thread
* help troubleshooting failures connect to an access point with iw/iwd
2021-04-21 4:51 ` Madhu
@ 2021-09-11 22:09 ` Madhu
2021-09-14 3:11 ` Madhu
0 siblings, 1 reply; 5+ messages in thread
From: Madhu @ 2021-09-11 22:09 UTC (permalink / raw)
To: linux-wireless
I've been using wpa_supplicant with rtw88 and b43 cards to connect to
a wpa-psk home router successfully for many years. This was with
-Wext. However I'm not able to accomplish this with iw or iwd.
$iw --version
iw version 5.9
$ iw dev wlan0 connect SSID key psk:<64bits> PSK CCMP CCMP
command failed: Invalid argument (-22)
- This always fails with this message. corresponding parameters work
with wpa_supplicant.
$/usr/libexec/iwd --version
1.17
$/usr/libexec/iwd -d
$ iwctl station wlan0 get-hidden-access-points
$ iwctl --passphrase=XXX station wlan0 connect SSID
If this connects it always immediately disconnects
kernel: [86195.924708] wlan0: authenticate with 58:xx:6e:xx:51:e4
kernel: [86196.264641] wlan0: send auth to 58:xx:6e:xx:51:e4 (try 1/3)
kernel: [86196.268477] wlan0: authenticated
kernel: [86196.274379] wlan0: associate with 58:xx:6e:xx:51:e4 (try 1/3)
kernel: [86196.281420] wlan0: RX AssocResp from 58:xx:6e:xx:51:e4 (capab=0x411 status=0 aid=1)
kernel: [86196.281491] rtw_8822ce 0000:xx:00.0: sta 58:xx:6e:xx:51:e4 joined with macid 0
kernel: [86196.282235] wlan0: associated
kernel: [86238.445926] wlan0: deauthenticated from 58:xx:6e:xx:51:e4 (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA)
kernel: [86238.594381] rtw_8822ce 0000:xx:00.0: sta 58:xx:6e:xx:51:e4 with macid 0 left
- So an connection, after authentication immediately deauthenticates
with (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA). The deauthentication
happens when any packet is to be sent on the interface
- In the case of b43 any authenticated connection also deauthenticates
but with (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
- These are also the failure modes when iwd is used under
NetworkManager-1.33.2
- I tried connman-1.40, but that didn't work at all It kept putting
the device into ad-hoc mode before trying to connect, and the
connection fails (even if i set the device in station mode via
iwctl, connman sets it to ad-hoc mode)
I'm stumped on how to debug this - I'm seeking any suggestions on what
to look at the netlink layer to track down these problems.
I may be missing something basic, if you can spot it please let me
know.
[latest 5.10 kernel with both in-kernel rt88 drivers and lwfinger from
april 2021]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: help troubleshooting failures connect to an access point with iw/iwd
2021-09-11 22:09 ` help troubleshooting failures connect to an access point with iw/iwd Madhu
@ 2021-09-14 3:11 ` Madhu
0 siblings, 0 replies; 5+ messages in thread
From: Madhu @ 2021-09-14 3:11 UTC (permalink / raw)
To: linux-wireless
* I Wrote on Sun, 12 Sep 2021 03:39:32 +0530 (IST),
in <20210912.033932.2187976226343353888.enometh@meer.net> :
> I've been using wpa_supplicant with rtw88 and b43 cards to connect to
> a wpa-psk home router successfully for many years. This was with
> -Wext. However I'm not able to accomplish this with iw or iwd.
The iwd part of the story has a resolution:
> $/usr/libexec/iwd --version
> 1.17
> $/usr/libexec/iwd -d
> $ iwctl station wlan0 get-hidden-access-points
> $ iwctl --passphrase=XXX station wlan0 connect SSID
>
> If this connects it always immediately disconnects
>
> kernel: [86195.924708] wlan0: authenticate with 58:xx:6e:xx:51:e4
> kernel: [86196.264641] wlan0: send auth to 58:xx:6e:xx:51:e4 (try 1/3)
> kernel: [86196.268477] wlan0: authenticated
> kernel: [86196.274379] wlan0: associate with 58:xx:6e:xx:51:e4 (try 1/3)
> kernel: [86196.281420] wlan0: RX AssocResp from 58:xx:6e:xx:51:e4
> (capab=0x411 status=0 aid=1)
> kernel: [86196.281491] rtw_8822ce 0000:xx:00.0: sta 58:xx:6e:xx:51:e4
> joined with macid 0
> kernel: [86196.282235] wlan0: associated
> kernel: [86238.445926] wlan0: deauthenticated from 58:xx:6e:xx:51:e4
> (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA)
> kernel: [86238.594381] rtw_8822ce 0000:xx:00.0: sta 58:xx:6e:xx:51:e4 with macid 0 left
>
> - So an connection, after authentication immediately deauthenticates
> with (Reason: 6=CLASS2_FRAME_FROM_NONAUTH_STA). The deauthentication
> happens when any packet is to be sent on the interface
As was pointed out, this is avoided by a
[General]
ControlPortOverNL80211=False
item in /etc/iwd/main.conf
The other problems are outstanding.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-09-14 3:11 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-04-20 1:02 rtw88 strange killall behaviour with nm Madhu
2021-04-20 4:34 ` Klaus Müller
2021-04-21 4:51 ` Madhu
2021-09-11 22:09 ` help troubleshooting failures connect to an access point with iw/iwd Madhu
2021-09-14 3:11 ` Madhu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).