Date: Sun, 19 Jan 2025 20:25:20 +0000 From: bugzilla-noreply@freebsd.org To: wireless@FreeBSD.org Subject: [Bug 247528] rtwn(4) RTL8192EU usb wifi dongle can't connect to AP Message-ID: <bug-247528-21060-ieYvfqK1d0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-247528-21060@https.bugs.freebsd.org/bugzilla/> References: <bug-247528-21060@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247528 --- Comment #60 from Adrian Chadd <adrian@freebsd.org> --- I've been digging deep in this and i've found some fun stuff. First, the power up / down / up sequencing problem. there's code in rtl8192= eu that doesn't exist at all in rtl8xxxu in linux. If I just delete them, the power up / down / up / down sequence doesn't break for me. https://reviews.freebsd.org/D48428 Second, there's some extra delays in the rtl8192eu RF register programming = in rtl8xxxu - it looks like some bit is toggled high -> low to kick start some hardware shifting/state machine. https://reviews.freebsd.org/D48512 Third, after tracing the write sleeps in cy@'s patch through the setup path= , it turns out we only need a sleep at the end of the channel programming, not f= or every write. https://reviews.freebsd.org/D48517 The last one is interesting. I added setting the CCX report bit in the TX descriptor for raw frames, so I'd get a per-frame report. However, when this condition occurs, I don't get /any/ response. It's like the frame isn't even attempted to be sent. So, I checked the contents of TXPAUSE after the chann= el config, and it's 0x0f and 0x4f, not 0x0 - so SOME queues are blocked. I also tried logging it during the TX path and yes, it's non-zero too during association attempts - however since the net80211 comlock is held during sc= ans, and net80211 txlock is held during normal transmit, things blew up pretty quickly there. (I'll fix those locks later.) Linux also retries the auth send more than once, whereas freebsd only tries= it once. If the NIC isn't ready or fails to send it with its hardware/firmware retry setup, then association fails. This is also likely suboptimal and fix= ing this in net80211 would be awesome, but again, we'll have to tackle that lat= er. So, I'd like cy@ and others w/ an RTL8192EU to try the three above diffs and report back. Let's see if it improves things or not. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-247528-21060-ieYvfqK1d0>