svpcom / rtl8812au

Patched rtl88xxau drivers for wfb-ng
https://github.com/svpcom/wfb-ng
GNU General Public License v2.0
103 stars 64 forks source link

allow up to 4052 byte packets #31

Closed tpwrules closed 8 months ago

tpwrules commented 8 months ago

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.

svpcom commented 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.

tpwrules commented 8 months ago

I'm not really sure I could. I definitely just got lucky with this change. Where is the 5.2.20 code broken exactly?

svpcom commented 8 months ago

@tpwrules https://github.com/svpcom/rtl8812au/blob/v5.2.20/hal/phydm/phydm_phystatus.c#L1795 https://github.com/svpcom/rtl8812au/blob/v5.2.20/hal/phydm/phydm_phystatus.c#L1837

tpwrules commented 8 months ago

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?

svpcom commented 8 months ago

Because now 8812au is only one hardware that have working injection. ath9k and rt28xx is EOL

tpwrules commented 8 months ago

Why does it matter if it breaks when not using injection?

svpcom commented 8 months ago

@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

tpwrules commented 7 months ago

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.

svpcom commented 7 months ago

@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