Can't use wireless adapter based on RealTek 8188 chip with driver urtwn. How-To-Repeat: Insert usb wireless stick and boot FreeBSD.
Responsible Changed From-To: freebsd-amd64->freebsd-wireless reclassify.
Its hard to tell, but my scan of the internet seems to indicate that this is a chipset variant that isn't supported by urtwn(4). If this is a "v2" chipset then I think it applies. I'm not real sure how to tell if this link is applicable to you or not. http://www.raspberrypi.org/forums/viewtopic.php?f=91&t=29752 It looks like this is a rtl8188eu as opposed to a supported rtl8188cus. In linux-land they are seperate driver modules. sean
I'm having this issue, but I'm sure I have the v1 chip: urtwn0: <vendor 0x0bda product 0x8176, class 0/0, rev 2.00/2.00, addr 4> on usbus0 urtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R After setting hw.usb.urtwn.debug=1 I see: urtwn_newstate: INIT -> INIT urtwn_load_firmware: FW V60.0 10-40 20:25 urtwn_newstate: INIT -> SCAN urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_newstate: SCAN -> AUTH urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_newstate: AUTH -> ASSOC urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_newstate: ASSOC -> RUN urtwn_ra_init: mode=0x4 rates=0x00000fff, basicrates=0x0000000f urtwn_ra_init: maxbasicrate=3 urtwn_ra_init: maxrate=11 urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue urtwn_bulk_tx_callback: urtwn_bulk_tx_callback: empty pending queue
Same kind of problem here, my USB key TP-Link model TL-WN823N is not supported on FreeBSD 11.0-RELEASE: Feb 28 22:19:48 po55ly kernel: ugen1.5: <Realtek> at usbus1 Feb 28 22:19:48 po55ly root: Unknown USB device: vendor 0x2357 product 0x0109 bus uhub3 I can send this key to an interested developer.
(In reply to Thierry Thomas from comment #4) This is RTL8192EU; it is supported in 12-CURRENT since r312680
(In reply to Andriy Voskoboinyk from comment #5) Thanks Andriy! Any plan to MFC it in 11-STABLE?
No, there are no such plans (r307529 breaks existing configs (due to renaming) + it seems to be a bit incompatible with 11.0 net80211 since r312315).
(In reply to Andriy Voskoboinyk from comment #7) That's inaccurate - I have just grabbed the same model (vendor product id) and stuck it in 10.3, and it recognised happily - the firmware wouldn't load properly because of the license flag and I didn't want to reboot, but I doubt that would be an issue. I was testing for a quirky issue in 11.1-RC3 which isn't recognising both the internal atheros 9377 (worked using a test image I built using the disc iso, but then didn't work after installed using the memstick image) - no amount of kldload'ing and rebooting is getting it going. From what I've read via the forums, the tp-link 823N is recognised in the urtwn driver and uses the rtl8192cfw[TU] firmware - confirmed in 10.3. That's why I specifically bought the device as I knew it worked. So is this a bug in 11 somewhere then? Maybe a wider issue in 802.11?
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
^Triage: - OP report did not contain FreeBSD version or specific device information. - If this is still an issue in supported (non-EoL) FreeBSD versions, please re-open the issue with additional details and steps to reproduce