TL-WN823N dongle not connecting to WiFi

javanx · January 9, 2023, 1:01pm

I recently bought a TL-WN823N wifi dongle because it was listed as supported in Haiku Hardware Database

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.

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

Is there anything I can do to fix it?

nephele · January 9, 2023, 2:04pm

Please open a ticket at https://dev.haiku-os.org instead

javanx · January 9, 2023, 5:59pm

done! #18209 (TL-WN823N dongle not connecting to WiFi) – Haiku

xoblite · January 10, 2023, 1:15pm

I have had similar issues with another reportedly supported USB WiFi adapter, the TP-Link TL-WN725N. Some output included below; on a previous attempt I got only “No route to host” errors while trying to PING my next hop gateway. Hence I am honestly not quite sure anymore whether this is only a (RealTek?) WiFi issue or if it also includes IP routing issues? (DHCP seems mostly OK, though I got some weird broadcast address at one point). Any thoughts @waddlesplash ?

Anyway, both Ubuntu Linux 22.11 and Windows 10 Pro work fine as expected, and reports good signal strength today (so we can rule that one out here, although weak signal strengths also seem to be a Haiku issue in some cases with frequently dropped connections as a result). I previously also tried GhostBSD (desktop distro based on FreeBSD) which did not work, as well as OpenBSD (command line) which also did not work. Please let me know if there are any cold/warm boot aspects to consider as well though?

0bda:8179 /dev/bus/usb/1/2/3/1 "Realtek Semiconductor Corp." "RTL8188EUS 802.11n Wireless Network Adapter" ver. 0000

Class info	Vendor Specific Class (Vendor Specific Subclass, Vendor Specific Protocol)
Device name	RTL8188EUS 802.11n Wireless Network Adapter
Device paths	unknown
device/bus	usb
device/driver	bus_managers/usb/device/driver_v1
device/flags	2
device/id	0x8179
device/pretty name	USB device
device/vendor	0xbda
Driver used	unknown
Manufacturer	Realtek Semiconductor Corp.
usb/class	0xff
usb/id	111
usb/protocol	0xff
usb/subclass	0xff

/dev/net/realtekwifi/0
        Hardware type: Ethernet, Address: 1c:61:b4:97:21:4b
        Media type: 802.11n(g)
        Network: wlan2.xoblite.net, Address: 38:d5:47:dc:ae:80, WPA2, PSK/CCMP
        inet addr: 172.16.1.112, Bcast: 172.16.1.255, Mask: 255.255.255.0
        MTU: 2294, Metric: 0, up broadcast link auto-configured
        Receive: 523 packets, 0 errors, 32493 bytes, 0 mcasts, 0 dropped
        Transmit: 301 packets, 10 errors, 30336 bytes, 0 mcasts, 0 dropped
        Collisions: 0

~> ping 172.16.1.1
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.1: icmp_seq=25 ttl=64 time=13005.181 ms
64 bytes from 172.16.1.1: icmp_seq=38 ttl=64 time=4.884 ms
ping: sendto: No buffer space available
ping: wrote 172.16.1.1 64 chars, ret=-1
64 bytes from 172.16.1.1: icmp_seq=93 ttl=64 time=8.774 ms
64 bytes from 172.16.1.1: icmp_seq=99 ttl=64 time=5004.067 ms
64 bytes from 172.16.1.1: icmp_seq=104 ttl=64 time=3.966 ms
64 bytes from 172.16.1.1: icmp_seq=129 ttl=64 time=5.611 ms
ping: sendto: No buffer space available
ping: wrote 172.16.1.1 64 chars, ret=-1
--- 172.16.1.1 ping statistics ---
205 packets transmitted, 6 packets received, 97% packet loss
round-trip min/avg/max/std-dev = 3.966/3005.413/13005.181/4830.122 ms
~>

...
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: [net/realtekwifi/0] beacon miss, mode STA state RUN
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: [net/realtekwifi/0] beacon miss, mode STA state RUN
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
KERN: wlan_control: 9234, 20
KERN: Last message repeated 2 times.
KERN: wlan_control: 9234, 16
KERN: wlan_control: 9234, 17
KERN: wlan_control: 9234, 26
KERN: wlan_control: 9234, 103
KERN: ieee80211_notify_scan_done
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9234, 18
KERN: wlan_control: 9234, 7
KERN: wlan_control: 9234, 95
KERN: wlan_control: 9234, 17
KERN: wlan_control: 9234, 26
KERN: wlan_control: 9234, 21
KERN: [net/realtekwifi/0] [38:d5:47:dc:ae:80] station assoc via MLME
KERN: [net/realtekwifi/0] ieee80211_alloc_node 0xffffffff82fe8000<38:d5:47:dc:ae:80> in station table
KERN: [net/realtekwifi/0] [38:d5:47:dc:ae:80] ieee80211_alloc_node: inact_reload 2
KERN: [net/realtekwifi/0] [38:d5:47:dc:ae:80] switch station to HT20 channel 2417/0x10480
KERN: [net/realtekwifi/0] node_reclaim: remove 0xffffffff82fc0000<38:d5:47:dc:ae:80> from station table, refcnt 0
KERN: [net/realtekwifi/0] set WME_AC_BE (chan) [acm 0 aifsn 3 logcwmin 4 logcwmax 10 txop 0]
KERN: [net/realtekwifi/0] set WME_AC_BE (bss ) [acm 0 aifsn 3 logcwmin 4 logcwmax 10 txop 0]
KERN: [net/realtekwifi/0] set WME_AC_BK (chan) [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop 0]
KERN: [net/realtekwifi/0] set WME_AC_BK (bss ) [acm 0 aifsn 7 logcwmin 4 logcwmax 10 txop 0]
KERN: [net/realtekwifi/0] set WME_AC_VI (chan) [acm 0 aifsn 2 logcwmin 3 logcwmax 4 txop 94]
KERN: [net/realtekwifi/0] set WME_AC_VI (bss ) [acm 0 aifsn 2 logcwmin 3 logcwmax 4 txop 94]
KERN: [net/realtekwifi/0] set WME_AC_VO (chan) [acm 0 aifsn 2 logcwmin 2 logcwmax 3 txop 47]
KERN: [net/realtekwifi/0] set WME_AC_VO (bss ) [acm 0 aifsn 2 logcwmin 2 logcwmax 3 txop 47]
KERN: [net/realtekwifi/0] update WME_AC_BE (chan+bss) [acm 0 aifsn 2 logcwmin 4 logcwmax 10 txop 0]
KERN: [net/realtekwifi/0] ieee80211_wme_updateparams_locked: WME params updated, cap_info 0xfe
KERN: [net/realtekwifi/0] ieee80211_new_state_locked: SCAN -> AUTH (nrunning 0 nscanning 0)
KERN: [net/realtekwifi/0] ieee80211_newstate_cb: SCAN -> AUTH arg 192
KERN: [net/realtekwifi/0] sta_newstate: SCAN -> AUTH (192)
KERN: [net/realtekwifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2647) 0xffffffff82fe8000<38:d5:47:dc:ae:80> refcnt 3
KERN: [net/realtekwifi/0] [38:d5:47:dc:ae:80] recv auth frame with algorithm 0 seq 2
KERN: [net/realtekwifi/0] ieee80211_new_state_locked: AUTH -> ASSOC (nrunning 0 nscanning 0)
KERN: [net/realtekwifi/0] ieee80211_newstate_cb: AUTH -> ASSOC arg 0
KERN: [net/realtekwifi/0] sta_newstate: AUTH -> ASSOC (0)
KERN: [net/realtekwifi/0] ieee80211_ref_node (ieee80211_send_mgmt:2647) 0xffffffff82fe8000<38:d5:47:dc:ae:80> refcnt 3
KERN: [net/realtekwifi/0] ieee80211_parse_wmeparams: WME: 0: acm=0 aifsn=3 logcwmin=4 logcwmax=10 txopLimit=0
KERN: [net/realtekwifi/0] ieee80211_parse_wmeparams: WME: 1: acm=0 aifsn=7 logcwmin=4 logcwmax=10 txopLimit=0
KERN: [net/realtekwifi/0] ieee80211_parse_wmeparams: WME: 2: acm=0 aifsn=2 logcwmin=3 logcwmax=4 txopLimit=94
KERN: [net/realtekwifi/0] ieee80211_parse_wmeparams: WME: 3: acm=0 aifsn=2 logcwmin=2 logcwmax=3 txopLimit=47
KERN: [net/realtekwifi/0] ieee80211_wme_updateparams_locked: WME params updated, cap_info 0x4
KERN: [net/realtekwifi/0] [38:d5:47:dc:ae:80] assoc success at aid 21: long preamble, short slot time, QoS, HT20 (+AMPDU) (+AMSDU)
KERN: [net/realtekwifi/0] ieee80211_new_state_locked: ASSOC -> RUN (nrunning 0 nscanning 0)
KERN: [net/realtekwifi/0] ieee80211_newstate_cb: ASSOC -> RUN arg 16
KERN: [net/realtekwifi/0] sta_newstate: ASSOC -> RUN (16)
KERN: ieee80211_notify_node_join
KERN: [net/realtekwifi/0] [38:d5:47:dc:ae:80] ieee80211_node_authorize: inact_reload 20
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 1
KERN: [net/realtekwifi/0] ieee80211_ref_node (ht_send_action_ba_addba:3054) 0xffffffff82fe8000<38:d5:47:dc:ae:80> refcnt 4
KERN: /dev/net/realtekwifi/0: link up, media 0x860098 quality 1000 speed 0
DAEMON 'DHCP': /dev/net/realtekwifi/0: Send DHCP_REQUEST for 172.16.1.112 to 255.255.255.255:67
KERN: wlan_control: 9235, 1
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9234, 19
DAEMON 'DHCP': /dev/net/realtekwifi/0: Send DHCP_REQUEST to 255.255.255.255:67
DAEMON 'DHCP': /dev/net/realtekwifi/0: Received DHCP_ACK from 172.16.1.1
DAEMON 'DHCP':   server: 172.16.1.1
DAEMON 'DHCP':   lease time: 86400 seconds
DAEMON 'DHCP':   renewal time: 40490 seconds
DAEMON 'DHCP':   rebinding time: 72890 seconds
DAEMON 'DHCP':   subnet: 255.255.255.0
DAEMON 'DHCP':   broadcast: 172.16.1.255
DAEMON 'DHCP':   nameserver[0]: 172.16.1.1
DAEMON 'DHCP':   gateway: 172.16.1.1
DAEMON 'DHCP': /dev/net/realtekwifi/0: DHCP status = No error
KERN: wlan_control: 9234, 19
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
KERN: wlan_control: 9235, 15
KERN: wlan_control: 9235, 76
...

nephele · January 10, 2023, 4:17pm

@xoblite I’ve already linked to the bugtracker, javanx opened a ticket and waddlesplash already responded there.

Why are you posting logs here?
Please use the bugtracker!

xoblite · January 10, 2023, 6:23pm

Because I wasn’t sure whether this was isolated to WiFi and therefore wanted waddlesplash’s expertise in the matter. Speaking of which…

KERN: PANIC: bounce buffer already in use!
KERN: Welcome to Kernel Debugging Land...
KERN: Thread 812 "/dev/net/dec21xxx/0 consumer" running on CPU 8
KERN: stack trace for thread 812 "/dev/net/dec21xxx/0 consumer"
KERN:     kernel stack: 0xffffffff8dfef000 to 0xffffffff8dff4000
KERN: frame                       caller             <image>:function + offset
KERN:  0 ffffffff8dff3548 (+  24) ffffffff80145d5c   <kernel_x86_64> arch_debug_call_with_fault_handler + 0x16
KERN:  1 ffffffff8dff3560 (+  80) ffffffff800af168   <kernel_x86_64> debug_call_with_fault_handler + 0x78
KERN:  2 ffffffff8dff35b0 (+  96) ffffffff800b0783   <kernel_x86_64> kernel_debugger_loop(char const*, char const*, __va_list_tag*, int) + 0xf3
KERN:  3 ffffffff8dff3610 (+  80) ffffffff800b0b1e   <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x6e
KERN:  4 ffffffff8dff3660 (+ 240) ffffffff800b0e77   <kernel_x86_64> panic + 0xb7
KERN:  5 ffffffff8dff3750 (+  64) ffffffff81a8d1c6   </boot/system/add-ons/kernel/drivers/dev/net/dec21xxx> _prepare_bounce_buffer(bus_dmamap*, unsigned long, int) + 0xa6
KERN:  6 ffffffff8dff3790 (+  96) ffffffff81a8d470   </boot/system/add-ons/kernel/drivers/dev/net/dec21xxx> bus_dmamap_load_mbuf_sg + 0x120
KERN:  7 ffffffff8dff37f0 (+ 576) ffffffff81a80ad5   </boot/system/add-ons/kernel/drivers/dev/net/dec21xxx> tulip_txput + 0x85
KERN:  8 ffffffff8dff3a30 (+  48) ffffffff81a8102c   </boot/system/add-ons/kernel/drivers/dev/net/dec21xxx> tulip_start_locked + 0x5c
KERN:  9 ffffffff8dff3a60 (+  32) ffffffff81a81331   </boot/system/add-ons/kernel/drivers/dev/net/dec21xxx> tulip_start + 0x31
KERN: 10 ffffffff8dff3a80 (+  64) ffffffff81a90ca2   </boot/system/add-ons/kernel/drivers/dev/net/dec21xxx> ether_output + 0xd2
KERN: 11 ffffffff8dff3ac0 (+  80) ffffffff81a8f0c1   </boot/system/add-ons/kernel/drivers/dev/net/dec21xxx> compat_write + 0x81
KERN: 12 ffffffff8dff3b10 (+  96) ffffffff800ea618   <kernel_x86_64> _kern_write + 0xb8
KERN: 13 ffffffff8dff3b70 (+  32) ffffffff801688bb   <kernel_x86_64> write + 0x1b
KERN: 14 ffffffff8dff3b90 (+  96) ffffffff8169b0e8   </boot/system/add-ons/kernel/network/devices/ethernet> ethernet_send_data(net_device*, net_buffer*) + 0xb8
KERN: 15 ffffffff8dff3bf0 (+ 112) ffffffff81679fed   </boot/system/add-ons/kernel/network/datalink_protocols/ethernet_frame> ethernet_frame_send_data(net_datalink_protocol*, net_buffer*) + 0x10d
KERN: 16 ffffffff8dff3c60 (+ 160) ffffffff8cd8a157   </boot/system/add-ons/kernel/network/protocols/tcp> TCPEndpoint::_SendQueued[clone .localalias] (bool, unsigned int) + 0x4b7
KERN: 17 ffffffff8dff3d00 (+  96) ffffffff8cd8c651   </boot/system/add-ons/kernel/network/protocols/tcp> TCPEndpoint::SegmentReceived(tcp_segment_header&, net_buffer*) + 0xd1
KERN: 18 ffffffff8dff3d60 (+ 272) ffffffff8cd88098   </boot/system/add-ons/kernel/network/protocols/tcp> tcp_receive_data(net_buffer*) + 0x308
KERN: 19 ffffffff8dff3e70 (+ 208) ffffffff8dfe84fe   </boot/system/add-ons/kernel/network/protocols/ipv4> ipv4_receive_data[clone .localalias] (net_buffer*) + 0x57e
KERN: 20 ffffffff8dff3f40 (+ 112) ffffffff8dfbcc62   </boot/system/add-ons/kernel/network/stack> device_consumer_thread(void*) + 0x152
KERN: 21 ffffffff8dff3fb0 (+  32) ffffffff8008cb98   <kernel_x86_64> common_thread_entry(void*) + 0x38
KERN: 22 ffffffff8dff3fd0 (+1912651824) ffffffff8dff3fe0   11496:/dev/net/dec21xxx/0 consumer_81@0xffffffff8dfef000 + 0x4fe0

nephele · January 10, 2023, 6:48pm

Please post kdls to the bugtracker, they don’t do any good in forum posts.

Starcrasher · January 10, 2023, 7:19pm

Don’t worry about posting something that could be unrelated. Anyway, devs will tell you if it is the case. Once a problem is reported on bugtracker, it is better to post all evidences of it there, even if you are not the one who opened the ticket.
The reason to this is optimize devs time. As you know Haiku devs are not legion, so depending priority, a bug can take from several days to several years to be closed. Meantime, probably others will encounter the same problem. If infos are not centralized, people who will take care of the bug will end up with several places to check out. It can be already difficult to keep track with tickets duplicates, if you have to dig in forum threads, it can quickly become hell.
We want Haiku to continue, don’t we? So, let’s avoid to drive devs crazy.

javanx · January 10, 2023, 8:38pm

Oh !$@#… I had just ordered a TL-WN725N as a replacement for the TL-WN823N hoping that it would give me a working wireless on Haiku. It’s like the most supported dongle out there on any OS so I took for granted it would work on Haiku too

nephele · January 10, 2023, 9:34pm

It’s already supported though… waddlesplash asked for some info in the ticket, if it works on FreeBSD it’s probably just a bugfix needed then

PulkoMandy · January 10, 2023, 10:07pm

Only if you’re sure it’s exactly the same problem. If there is any doubt, creating a separate ticket is probably better (and we can always close it as duplicate if it turns out it was in fact the same). Unfortunately there’s no good way to “split” a ticket if it turns out it had two issues in it that turn out to have different causes.

waddlesplash · January 11, 2023, 5:27pm

I think it does work for other people, it not working seems a bit random. So you may not be out of luck anyway.

javanx · January 11, 2023, 8:33pm

It actually crashes the whole kernel for me. It does connect to wifi, but after a while the kernel panics

Istarian · January 12, 2023, 9:34pm

KERN: PANIC: bounce buffer already in use!
KERN: Welcome to Kernel Debugging Land…
KERN: Thread 812 “/dev/net/dec21xxx/0 consumer” running on CPU 8
KERN: stack trace for thread 812 “/dev/net/dec21xxx/0 consumer”
…

Might be pure coincidence, but the problem that @xoblite posted some KDL stuff from further up the
thread was referring to an issue with bounce buffers. That looks like it was related to wired ethernet, but…

Speculatively, if the driver works in FreeBSD but not in Haiku then maybe there’s a difference in Haiku’s handling of some fairly basic operation.

waddlesplash · January 13, 2023, 4:32am

I am very confident in saying that problem is completely unrelated from the Realtek WiFi one. This problem with bounce-buffers is related to PCIe DMA, which of course is not used by the driver at all when working with a USB device. It deserves a separate ticket (or is there already one somewhere…?)