rtwn_usb(4) lists TL-WN821N v5 as a supported device but yesterdays -current fails to recognise it due to a missing entry in usbdevs. With the following patch I was able to use this device (FCC ID: TE7WN821NV5) and a TP-Link TL-WN722N v2 (FCC ID: TE7WN722NV2) after loading rtwn_usb and setting legal.realtek.license_ack=1 as described in rtwnfw(4). Kind regards, Kai-Uwe Eckhardt --- /usr/src/sys/dev/usb/usbdevs.orig 2017-04-26 12:01:35.568108000 +0200 +++ /usr/src/sys/dev/usb/usbdevs 2017-04-25 14:37:09.992247000 +0200 @@ -4526,8 +4526,10 @@ /* TP-Link products */ product TPLINK T4U 0x0101 Archer T4U +product TPLINK WN821NV5 0x0107 TL-WN821N v5 product TPLINK WN822NV4 0x0108 TL-WN822N v4 product TPLINK WN823NV2 0x0109 TL-WN823N v2 +product TPLINK WN722NV2 0x010c TL-WN722N v2 /* Trek Technology products */ product TREK THUMBDRIVE 0x1111 ThumbDrive --- /usr/src/sys/dev/rtwn/usb/rtwn_usb_attach.h.orig 2017-04-26 09:40:52.582554000 +0200 +++ /usr/src/sys/dev/rtwn/usb/rtwn_usb_attach.h 2017-04-26 09:46:56.057307000 +0200 @@ -109,6 +109,7 @@ RTWN_RTL8192EU_DEV(REALTEK, RTL8192EU), RTWN_RTL8192EU_DEV(TPLINK, WN822NV4), RTWN_RTL8192EU_DEV(TPLINK, WN823NV2), + RTWN_RTL8192EU_DEV(TPLINK, WN821NV5), #undef RTWN_RTL8192EU_DEV /* RTL8188EU */ @@ -120,6 +121,7 @@ RTWN_RTL8188EU_DEV(ELECOM, WDC150SU2M), RTWN_RTL8188EU_DEV(REALTEK, RTL8188ETV), RTWN_RTL8188EU_DEV(REALTEK, RTL8188EU), + RTWN_RTL8188EU_DEV(TPLINK, WN722NV2), #undef RTWN_RTL8188EU_DEV /* RTL8812AU */
Looks good to me. Do you have dmesg for the adapter? --HPS
dmesg for WN821NV5: rtwn0 on uhub2 rtwn0: <802.11n NIC > on usbus0 rtwn0: MAC/BB RTL8192EU, RF 6052 2T2R ugen0.4: <Realtek 802.11n NIC> at usbus0 (disconnected) dmesg for WN722NV2: ugen0.4: <Realtek 802.11n NIC> at usbus0 rtwn0 on uhub2 rtwn0: <Realtek 802.11n NIC, class 0/0, rev 2.00/0.00, addr 4> on usbus0 rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R Kai-Uwe
I just found out that the WN821NV5 is unable to connect with WPA-PSK. I only tested with an unencrypted access point. The WN722N connects without problems with the same configuration files. I get no error reports in dmesg, ifconfig shows wlan0: flags=8c43<UP,BROADCAST,RUNNING,OACTIVE,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 18:d6:c7:15:6e:42 inet6 fe80::1ad6:c7ff:fe15:6e42%wlan0 prefixlen 64 scopeid 0x3 nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g (autoselect) status: no carrier ssid "" channel 6 (2437 MHz 11g ht/20) regdomain ETSI country DE authmode WPA1+WPA2/802.11i privacy ON deftxkey UNDEF txpower 30 bmiss 7 scanvalid 60 protmode CTS ht20 ampdulimit 8k ampdudensity 16 shortgi -stbc -ldpc wme roaming MANUAL groups: wlan ifconfig shows the desired network at S:N -65:-95 but wpa_cli is unable to connect: Authentication timed out. I will try to get some debug info and play with hardware crypto, etc. Kai-Uwe
The WN821N behaves really strange. Today ifconfig wlan0 scan showed only three APs instead of about 30 like yesterday. After repeating it several times with the same result I shutdown, rebooted and now it shows 30 again but an AP in 3 meters distance is sometimes present and sometimes missing. Turning debugging on with sysctl -w dev.rtwn.0.debug=1 shows a bunch of messages like this: Apr 29 13:35:31 x201 kernel: rtwn0: rtwn_bulk_tx_callback: empty pending queue Apr 29 13:35:31 x201 kernel: rtwn0: rtwn_raw_xmit: called; m 0xfffff8000adac300, ni 0xfffffe00023c1000 Apr 29 13:35:31 x201 kernel: rtwn0: rtwn_raw_xmit: called; m 0xfffff8000aa41a00, ni 0xfffffe00023c1000 Apr 29 13:35:31 x201 kernel: rtwn0: rtwn_bulk_tx_callback: empty pending queue Apr 29 13:35:32 x201 kernel: rtwn0: rtwn_raw_xmit: called; m 0xfffff8000adac300, ni 0xfffffe00023c1000 Apr 29 13:35:32 x201 kernel: rtwn0: rtwn_raw_xmit: called; m 0xfffff8000aa41a00, ni 0xfffffe00023c1000 Apr 29 13:35:32 x201 kernel: rtwn0: rtwn_bulk_tx_callback: empty pending queue Apr 29 13:36:00 x201 wpa_supplicant[659]: wlan0: Trying to associate with 9c:80: df:85:f7:b9 (SSID='balkonia' freq=2462 MHz) Apr 29 13:36:10 x201 wpa_supplicant[659]: wlan0: Authentication with 9c:80:df:85 :f7:b9 timed out. Apr 29 13:36:10 x201 wpa_supplicant[659]: wlan0: CTRL-EVENT-DISCONNECTED bssid=9 c:80:df:85:f7:b9 reason=3 locally_generated=1 Apr 29 13:36:10 x201 wpa_supplicant[659]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED i d=3 ssid="balkonia" auth_failures=1 duration=10 reason=CONN_FAILED ~ Ok, I will look at the frames actually sent with a Linux laptop and kismet, but it will take a few days. Looks like a good opportunity to learn something new about the kernel code ;-) Kai-Uwe
After some testing it turns out that the WN821 is kind of deaf, especially after sending. Mabey someone finds a hint in the linux driver from the vendor at http://www.tp-link.com/us/download/TL-WN821N.html#Driver in which I found the device ID and chip set to use: /*===TPLINK ID===========*/ {USB_DEVICE(0x2357, 0x0107),.driver_info = RTL8192E}, /* TP-Link - Cameo */ Quite possibly there are some calibration hints in the source but I didn't spot it on a first look. I was unable to compile the driver under Linux kernel 4.9, so I cannot test there either. Kai-Uwe
The bug can be closed. Both devices have been added to usbdevs and the WN821N v5 now works with WPA-PSK. Thanks, Kai-Uwe
Seems this was handled in r342156 and r342703 for rtwn_usb_attach.h from what I can see.
Hm, is there a regression in HEAD or a catch in configuration? I have WN821N which is detected in the same way as above and wpa_supplicant also timeouts during authentication with WPA-PSK. Sidenote: wpa_supplicant hangs if restarted, device must be unplugged to fix this.
It works for me with wpa-psk on yesterdays 14.0-CURRENT with this in rc.conf: wlans_rtwn0="wlan0" ifconfig_wlan0="WPA DHCP" create_args_wlan0="country DE regdomain ETSI" and the appropiate entry in wpa_supplicant.conf connecting to an 11g AP. Good luck, Kai-Uwe
Played a bit more with parameters without any success and also tried it in Linux where it fails in the same way until I force wext driver when starting wpa_supplicant. Don't want to waste more time on this, it was a backup option anyways.