Bug 188654 - rtwn(4) / rtwn_usb(4) TP-Link WL-725N (Realtek 8188) chip do not work
Summary: rtwn(4) / rtwn_usb(4) TP-Link WL-725N (Realtek 8188) chip do not work
Status: Closed Not Enough Information
Alias: None
Product: Base System
Classification: Unclassified
Component: wireless (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-wireless (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-15 12:50 UTC by Rostislav
Modified: 2020-07-31 03:34 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rostislav 2014-04-15 12:50:00 UTC
Can't use wireless adapter based on RealTek 8188 chip with driver urtwn.

How-To-Repeat: Insert usb wireless stick and boot FreeBSD.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2014-04-15 18:06:39 UTC
Responsible Changed
From-To: freebsd-amd64->freebsd-wireless

reclassify.
Comment 2 sbruno 2014-04-15 18:45:19 UTC
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
Comment 3 Steve Wills freebsd_committer 2015-04-15 01:15:18 UTC
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
Comment 4 Thierry Thomas freebsd_committer 2017-02-28 22:07:47 UTC
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.
Comment 5 Andriy Voskoboinyk freebsd_committer 2017-02-28 22:12:34 UTC
(In reply to Thierry Thomas from comment #4)
This is RTL8192EU; it is supported in 12-CURRENT since r312680
Comment 6 Thierry Thomas freebsd_committer 2017-02-28 22:34:28 UTC
(In reply to Andriy Voskoboinyk from comment #5)

Thanks Andriy!

Any plan to MFC it in 11-STABLE?
Comment 7 Andriy Voskoboinyk freebsd_committer 2017-02-28 22:37:54 UTC
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).
Comment 8 rocky 2017-07-20 23:37:11 UTC
(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?
Comment 9 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:48:54 UTC
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.
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2020-07-31 03:34:16 UTC
^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