TL-WN823N dongle not connecting to WiFi

[javanx]

I recently bought a TL-WN823N wifi dongle because it was listed as supported in ​https://hardware.besly.de/index.php?hardware=External_Wireless_Adapter

The kernel correctly recognises the wifi and enables it, but I see only 4/5 wifi networks instead of the usual 10-15 that actually exist around me. My own network is not listed and if I try to manually specify the SSID to connect to it, it fails. Under Windows the dongle works and is able to connect to my WiFi.

The only things I see in the logs while it’s trying to connect are

KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 78
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 16
KERN: wlan_control: 9235, 17
KERN: wlan_control: 9235, 26
KERN: wlan_control: 9235, 98
KERN: wlan_control: 9234, 20
KERN: Last message repeated 5 times.
KERN: wlan_control: 9234, 25
KERN: wlan_control: 9234, 16
KERN: wlan_control: 9234, 17
KERN: wlan_control: 9234, 26
KERN: wlan_control: 9234, 103
KERN: wlan_control: 9234, 25
KERN: wlan_control: 9234, 95

See also ​https://discuss.haiku-os.org/t/tl-wn823n-dongle-not-connecting-to-wifi/12934 for the discussion originating this ticket.

[javanx]

If Haiku allows to replace kernel modules at runtime (I'm not knowledgeable enough about haiku architecture to make any assumption here) and anyone can point me to how to rebuild the involved kernel module I can experiment on my own and try to understand what's going wrong.

[waddlesplash]

Please attach a syslog.

It isn't exactly possible to replace kernel modules at runtime, but you can at least blocklist the old driver, which will allow you to load a rebuilt version of the module after booting (but if you want to unload/reload it you will need to reboot.)

You may want to check if you can get this device to work on FreeBSD. If you can't, then at least the problem isn't in the port of the driver to Haiku, but fixing it may then be much more difficult.

[javanx]

I had attached content of my syslog since boot time. But it doesn't show much more of what I already embedded into the ticket description. Hope it helps by the way

[javanx]

SysLog content from boot

[javanx]

FreeBSD logs

[javanx]

FreeBSD dmesg

[javanx]

I also tested on FreeBSD using the FreeBSD image provided at ​https://download.freebsd.org/releases/VM-IMAGES/13.1-RELEASE/amd64/Latest/

FreeBSD was running in VirtualBox with networking disabled. The was dongle proxied to FreeBSD through USB. So from the point of view of FreeBSD it was an USB peripheral and the test should be as valid as natively booting FreeBSD

It worked fine and it was able to connect once configured. See the attached screenshots.

[javanx]

Want to point out that I tried also with a TL-WN725N which is usually more supported. With that one I was able to connect to WiFi, but the networking is very unstable (disconnects every 5 minutes or so) and it crashed the whole kernel after a while. I’ll attach the kernel crash for this one

[javanx]

Crash for TL-WN725N

[waddlesplash]

That's an assertion. It's coming from here: ​https://xref.landonf.org/source/xref/haiku/src/add-ons/kernel/drivers/network/wlan/realtekwifi/dev/rtwn/usb/rtwn_usb_rx.c#217

It's possible there's some USB problem leading to this, I guess, if it works with FreeBSD in VirtualBox. Can you test with Haiku in VirtualBox and see if it behaves any differently?

[javanx]

Replying to waddlesplash:

It's possible there's some USB problem leading to this, I guess, if it works with FreeBSD in VirtualBox. Can you test with Haiku in VirtualBox and see if it behaves any differently?

It might have been an USB problem, I use an USB-C to USB-A adapter to fit the dongle into the laptop and I might have accidentally moved it. I have used Haiku for a while after those kernel crashes and they haven't occurred anymore.

On the other side, the problem of the WiFi losing connection and trying to reconnect ever 2 minutes persists and makes the connection pretty unusable. Anything taking more than a few seconds to happen has a big chance of being truncated.

This is usually the message that I see when it disconnects

KERN: [net/realtekwifi/0] [c4:f1:74:98:73:27] discard frame, [realtekwifi] wrong version, fc 71:ff
Last message repeated 1 time
KERN: [net/realtekwifi/0] beacon miss, mode STA state RUN
Last message repeated 1 time
KERN: [net/realtekwifi/0] ieee80211_new_state_locked: RUN -> SCAN (nrunning 0 nscanning 0)
KERN: [net/realtekwifi/0] ieee80211_newstate_cb: RUN -> SCAN arg 0
KERN: [net/realtekwifi/0] sta_newstate: RUN -> SCAN (0)
KERN: ieee80211_notify_node_leave
KERN: /dev/net/realtekwifi/0: link down, media 0x60080 quality 1000 speed 0

[waddlesplash]

Does that problem occur on FreeBSD?

[waddlesplash]

Also, can you copy a syslog after having that problem a few times, and upload it here?

[javanx]

SysLog of TL-WN725N continuously disconnecting

[javanx]

Replying to waddlesplash:

Also, can you copy a syslog after having that problem a few times, and upload it here?

I attached syslog after 10 times or so that the disconnections happen. On FreeBSD it works fine. I also noticed that on FreeBSD it seems quite faster, on Haiku it does 1Mbps, while on FreeBSD downloading something is an order of magnitude faster at least.

[waddlesplash]

KERN: [net/realtekwifi/0] [cc:cc:cc:cc:cc:cc] discard deauth frame, [realtekwifi] bad frame type 0xc

That looks bad. "cc" is the usual thing uninitialized memory is filled with on KDEBUG (nightly) builds. Somehow we may not be copying buffers correctly, I suppose.

[javanx]

I'm wondering... is there an equivalent of txpower setting in haiku? Because I notice that when I use Haiku the signal quality of the wifi network is reported as being very low, even though I'm like 2 meters away from the access point.

[waddlesplash]

There isn't.

I looked through the USB compatibility functions again, and I didn't spot anything out of the ordinary that could lead to the use of uninitialized memory. In fact, the realtekwifi driver does its own buffer management and just asks the USB layer to use these when doing I/O, so there really shouldn't be a way uninitialized memory comes back. Of course, there could be something else going on, and the "cc" bytes aren't actually from Haiku in the first place.

[waddlesplash]

It seems most probable that there is some kind of buffer mismanagement going on, but I don't have any good ideas on what it would be or how to find it. Unless one of the FreeBSD developers has a bright idea, I doubt I will make much progress here since it doesn't seem to happen with the Realtek devices I was originally testing with...

[waddlesplash]

I guess you can also try testing on VirtualBox with Haiku as well, and then also on bare metal with SMP disabled to see if either of those things make any difference.

[waddlesplash]

Please retest after hrev58353.