Closed tpwrules closed 8 months ago
@tpwrules Thanks! Could you try to investigate why https://github.com/svpcom/rtl8812au/commit/9a99e8ce27f6c44bffa392e2534d501c58615551 triggers kernel panic (or deadlock, I don't remember exactly) when operating in normal (non-injection) mode.
This commit (now rolled back in master branch) is my attempt to backport newer code from 5.6.4.2 to 5.2.20, because in 5.2.20 RSSI evaluation for multiple antennas seems to be broken. Old code from Realtek tries to shift variable more that its width.
I'm not really sure I could. I definitely just got lucky with this change. Where is the 5.2.20 code broken exactly?
I see, it looks like that code is pretty tangled. I don't think I have time to investigate it right now unfortunately. Functionality outside of monitor mode is not a priority to me, I would just switch to other drivers if I needed it. Curious why maintaining that is a priority to you?
Because now 8812au is only one hardware that have working injection. ath9k and rt28xx is EOL
Why does it matter if it breaks when not using injection?
@tpwrules Because when cards is not in injection mode networkmanager can try to use it for normal connection and crash the machine. I've catch this in my development machine several times
Can you create a branch that exhibits this problem but has the RSSI evaluation fixed based on top of current master? I'm a little confused by the reverts and stuff.
@tpwrules Yes, see v5.2.20-rssi-fix-but-sometimes-crash
branch. To reproduce issue just try to connect to AP in normal (non injection/monitoring) mode
Tested on a pair of RTL8812AUs over USB2 on two different systems sending max size packets and receiving and verifying each packet. No kernel panics even on a heavily loaded system, whereas previously it was easy to trigger a panic or a rejection of the packet.
Seems to work fine even without the receive side change, but better safe than sorry.
Designed to work with max 4000 bytes of user data with wfb-ng.