Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter

[Alfred Perlstein]

On 10/6/13 8:21 AM, Julian H. Stacey wrote:
> I wrote Thu, 03 Oct 2013 23:28:43 +0200
>> Rui Paulo wrote:
>>> On 2 Oct 2013, at 16:57, Julian H. Stacey <j...@berklix.com> wrote:
>>>
>>>> Hi current@,
>>>> It seems I need if_urtwn driver for a really miniature WLAN USB stick,
>>>> & if_urtwn is only in current ?
>>>> man 4 if_urtwn refers to ports/net/urtwn-firmware-kmod which is missing ?
>>>
>>> This driver was never merged to FreeBSD 9.
>> OK, Thanks for confirmation.
>>
>>
>>> Can you use FreeBSD 10 instead?
>> Yes, easier than building from 9.X I guess (& helps test alpha :-).
>> I'll fetch from local mirror, per
>> http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044951.html
>>
>>
>>> The port reference in the man page is wrong. The firmware is now shipped as part of the base system.
>> Oh nice, easier :-)
> I'm happy to report with 10.0-ALPHA4 /boot/loader.conf if_urtwn_load="YES"
> `ifconfig wlan0 scan` works OK. Thanks :-)
>
> Cheers,
> Julian

Cool!

I have a g4 tibook 12in with an if_bwn that doesn't really work at all.

I got one of these (if_urtwn) and it works enough to download about a
meg or so before the watchdog kicks in and I have to ifconfig down/up it
to get it to respond again.

I even have a patch pending to add the usb identifier for this.

Is there someone I can provide debug information for to help resolve this?

--
Alfred Perlstein

_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Thomas Mueller]

I just happened to be browsing man urtwn in NetBSD-current (6.99.23), and Edimax EW-7811Un is listed as supported by this driver.

This strongly suggests it should work for FreeBSD-current (barring bugs).


Tom

[Julian H. Stacey]

Hi Alfred & cc current.

I too am seeing
urtwn0: timeout waiting for checksum report
sometimes I can scan & sometimes not,
(whereas with a run0: stick I have no problem)
I've not got as far as trying to move data.
I'd appreciate any patches you have Alfred

Cheers,
Julian
--
Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com
Reply below not above, like a play script. Indent old text with "> ".
Send plain text. No quoted-printable, HTML, base64, multipart/alternative.

[Julian H. Stacey]

> I too am seeing
> urtwn0: timeout waiting for checksum report

&
urtwn0: at uhub3, port 3, addr 4 (disconnected)
(BTW there's no external hub, uhub3 must be inside laptop,
& there's no loose connection, laptop was not touched, all work was remote)

PS a typical sample comparison of scanned signal strengths
of one of the ~15 nets localy:
54M -49:-86 100 EP RSN WPA WME run0 big stick,
54M -69:-95 100 EP RSN WPA WME urtwn0 nano edimax EW-7811Un
so the edimax is typically down about 20 on left column on all ~15 local nets.

The aerial must be a minute fraction of the wavelength.
I suppose wavelengths are is approx:
3 x 10^8 metre/second / 2.4 GHz = 3/2.4 x 10^(8-9) m = 12.5 cm
& ~6cm for 5GHz band.

[Adrian Chadd]

Hi,

Note the noise floor differences.. wonder why that is.

Rui ported the uwrtn stuff, right? He may be able to help. The driver is
recent and its likely there are bugs to shake out.

-adrian

[Alfred Perlstein]

Unfortunately all my time right now is being spent syncing changes to
FreeNAS from our commercial product TrueNAS to improve both products. I
tried to look at the code but my eyes quickly went cross and I had to
get back to build stuff.

-Alfred

[Julian H. Stacey]

Hi all,

Adrian Chadd wrote:
> Note the noise floor differences.. wonder why that is.

Yes, more measurements etc at:
http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/share/man/man4/urtwn.4.REL=current.diff

> Rui ported the uwrtn stuff, right?

It seems others, so I added them:
To: ke...@freebsd.org
cc: dam...@openbsd.org
to ask if they have newer versions code or firmware to test ?

http://svnweb.freebsd.org/base/head/sys/dev/usb/wlan/if_urtwn.c?view=log
] Import Kevin Lo's port of urtwn(4) from OpenBSD. urtwn(4) is a driver for the
] Realtek RTL8188CU/RTL8192CU USB IEEE 802.11b/g/n wireless cards.
] This driver requires microcode which is available in FreeBSD ports:
] net/urtwn-firmware-kmod.
] Hiren ported the urtwn(4) man page from OpenBSD and Glen just commited a port
] for the firmware.
] Tested by: kevlo, hiren, gjb

> He may be able to help. The driver is
> recent and its likely there are bugs to shake out.

http://svnweb.freebsd.org/base/head/share/man/man4/urtwn.4?view=markup
The urtwn driver first appeared in OpenBSD 4.9 and FreeBSD 10.0.
The urtwn driver was written by Damien Bergamini <dam...@openbsd.org>.

Also Re. Thomas Mueller's

> I just happened to be browsing man urtwn in NetBSD-current
> (6.99.23), and Edimax EW-7811Un is listed as supported by this driver.

I See on FreeBSD, OpenBSD, NetBSD:

/pub/FreeBSD/branches/-current/src/sys/
dev/usb/wlan/if_urtwn.c
dev/usb/wlan/if_urtwnreg.h
contrib/dev/urtwn/urtwn-rtl8192cfwT.fw.uu
contrib/dev/urtwn/urtwn-rtl8192cfwU.fw.uu

http://svnweb.freebsd.org/base/head/sys/dev/usb/wlan/if_urtwn.c?view=markup
$OpenBSD: if_urtwn.c,v 1.16 2011/02/10 17:26:40 jakemsr Exp $
http://svnweb.freebsd.org/base/head/sys/dev/usb/wlan/if_urtwnreg.h?view=markup
http://svnweb.freebsd.org/base/head/sys/contrib/dev/urtwn/urtwn-rtl8192cfwT.fw.uu?view=markup
http://svnweb.freebsd.org/base/head/sys/contrib/dev/urtwn/urtwn-rtl8192cfwU.fw.uu?view=markup

http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/if_urtwn.c
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/if_urtwn.c?rev=1.32;content-type=text%2Fplain;only_with_tag=MAIN
$OpenBSD: if_urtwn.c,v 1.32 2013/09/30 05:18:57 jsg Exp $
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/usb/if_urtwnreg.h
http://www.openbsd.org/cgi-bin/man.cgi?query=urtwn&sektion=4&format=html
Can't find firmware BLOB[s] on openbsd.org site

http://netbsd.gw.com/cgi-bin/man-cgi?urtwn++NetBSD-current
/libdata/firmware/if_urtwn/rtl8192cfw.bin
/libdata/firmware/if_urtwn/rtl8192cfwU.bin
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/usb/if_urtwn.c?only_with_tag=MAIN
/* $NetBSD: if_urtwn.c,v 1.25 2013/08/10 21:15:26 jnemeth Exp $ */
/* $OpenBSD: if_urtwn.c,v 1.20 2011/11/26 06:39:33 ckuethe Exp $ */

[Julian H. Stacey]

> > Rui ported the uwrtn stuff, right?
>
> It seems others, so I added them:

Whoops, I missed "Rui" = "paulo" in commit logs. Added to cc. Sorry.

[Julian H. Stacey]

Ref.
http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045333.html

I jhs@ wrote

> > > Rui ported the uwrtn stuff, right?
> > It seems others, so I added them:
> Whoops, I missed "Rui" = "paulo" in commit logs. Added to cc. Sorry.

This has header with corrected addresses for
"Rui Paulo" <rpa...@freebsd.org>
(my typo. before)
"Damien Bergamini" <damien.b...@free.fr>
(after <dam...@openbsd.org> bounced on
reason: 550 5.1.1 <dam...@cvs.openbsd.org>..
& I pinged @free.fr & got no bounce )

[Rui Paulo]

On 8 Oct 2013, at 10:41, Julian H. Stacey <j...@berklix.com> wrote:

> I too am seeing
> urtwn0: timeout waiting for checksum report

Sorry, this is a know problem that I haven't been able to figure out... It probably exists in the OpenBSD driver as well. Usually retrying works.

--
Rui Paulo

[Alfred Perlstein]

On 10/15/13 11:13 PM, Rui Paulo wrote:
> On 8 Oct 2013, at 10:41, Julian H. Stacey <j...@berklix.com> wrote:
>
>> I too am seeing
>> urtwn0: timeout waiting for checksum report
> Sorry, this is a know problem that I haven't been able to figure out... It probably exists in the OpenBSD driver as well. Usually retrying works.
>
> --
> Rui Paulo
>
>
>

I have a "device timeout" problem with urtwn as well, but I haven't had
time to hack the driver to self-reset itself. boo :(

--
Alfred Perlstein

[Alexey Dokuchaev]

On Sun, Oct 06, 2013 at 10:24:09AM -0700, Alfred Perlstein wrote:
> I got one of these (if_urtwn) and it works enough to download about a meg
> or so before the watchdog kicks in and I have to ifconfig down/up it to
> get it to respond again.
>
> I even have a patch pending to add the usb identifier for this.

Same here; someone at $work bought couple of these teeny dongles. I've
applied small id patch (attached), and tried to use it (it reportedly
works flawlessly under Linux using this [*] driver). I could load the
module, but MAC address was clearly bogus (00:00:30:34:43:30); yet I've
created wlan0 just to find out that there is no list scan results, and
wpa_supplicant(8) gives me this in an endless loop (GENERIC kernel, so
I presume all wlan-related stuff should be in place):

Successfully initialized wpa_supplicant
ioctl[SIOCS80211, op=103, val=0, arg_len=128]: Device not configured
wlan0: Failed to initiate AP scan

This is on relatively fresh 11-CURRENT as of Oct 18th, i386. Any clues?
It would be nice to get more of these little guys to work, esp. there is
working Linux driver available for reference.

/danfe

[*] https://github.com/liwei/rpi-rtl8188eu

[Kevin Lo]

Your usb wlan dongles use RTL8188EU chip which is currently not
supported by any of drivers.

>
> ./danfe
>
> [*] https://github.com/liwei/rpi-rtl8188eu

Kevin

[Alexey Dokuchaev]

On Thu, Dec 19, 2013 at 09:56:31AM +0800, Kevin Lo wrote:
> Your usb wlan dongles use RTL8188EU chip which is currently not
> supported by any of drivers.

I see; I guess I should not have believed when I was told that most likely
all it would take is id-patch urtwn(4). ;-)

Does anyone know if support is being worked on? Given an increased
popularity of these dongles, perhaps a wiki page would be nice for
those of us who want to get an idea if some particular chip is supported
before buying them (online).

/danfe

[Thomas Mueller]

> On Thu, Dec 19, 2013 at 09:56:31AM +0800, Kevin Lo wrote:
> > Your usb wlan dongles use RTL8188EU chip which is currently not
> > supported by any of drivers.

> I see; I guess I should not have believed when I was told that most likely
> all it would take is id-patch urtwn(4). ;-)

> Does anyone know if support is being worked on? Given an increased
> popularity of these dongles, perhaps a wiki page would be nice for
> those of us who want to get an idea if some particular chip is supported
> before buying them (online).

> ./danfe

Better would be if manufacturers' and online vendors' websites would say what chipset their Ethernet, Bluetooth adapter, USB wi-fi adapter, etc use.

That would be useful for any prospective buyer, and would not require familiarity with any specific operating system.

But I see this is quite unusual; sometimes, but infrequently, it may be in downloadable PDF.

Tom

[Tom Evans]

On Thu, Dec 19, 2013 at 12:33 PM, Thomas Mueller
<muell...@bellsouth.net> wrote:
> Better would be if manufacturers' and online vendors' websites would say what chipset their Ethernet, Bluetooth adapter, USB wi-fi adapter, etc use.
>

I think manufacturers don't consider this relevant info, they sell
features, not the underlying spec. This allows them to chop and change
what chip is actually in a device depending on the vagaries of their
supply chain. Eg, Rev A, Rev B might be precisely the same packaging
but different chips underneath.

Suck for non Windows users, I agree.

Cheers

[Kevin Lo]

On 2013/12/19 17:51, Alexey Dokuchaev wrote:
> On Thu, Dec 19, 2013 at 09:56:31AM +0800, Kevin Lo wrote:
>> Your usb wlan dongles use RTL8188EU chip which is currently not
>> supported by any of drivers.
> I see; I guess I should not have believed when I was told that most likely
> all it would take is id-patch urtwn(4). ;-)
>
> Does anyone know if support is being worked on?

Don't know either. I'd like to port it after finishing RT5373
driver support. :-)

> Given an increased
> popularity of these dongles, perhaps a wiki page would be nice for
> those of us who want to get an idea if some particular chip is supported
> before buying them (online).

Here's a site you could use for info about your wireless device:
http://wikidevi.com/wiki/TP-LINK_TL-WN723N_v3

>
> ./danfe

Kevin

[Alexey Dokuchaev]

On Fri, Dec 20, 2013 at 01:35:37PM +0800, Kevin Lo wrote:
> I'd like to port it after finishing RT5373 driver support. :-)

Nice, looking forward to it. :)

> Here's a site you could use for info about your wireless device:
> http://wikidevi.com/wiki/TP-LINK_TL-WN723N_v3

Thank you Kevin.

/danfe

[Alexey Dokuchaev]

On Tue, Oct 15, 2013 at 11:13:56PM -0700, Rui Paulo wrote:
> On 8 Oct 2013, at 10:41, Julian H. Stacey <j...@berklix.com> wrote:
> > I too am seeing
> > urtwn0: timeout waiting for checksum report
>
> Sorry, this is a know problem that I haven't been able to figure out...
> It probably exists in the OpenBSD driver as well. Usually retrying works.

To augment this a bit: I also came across one of these dongles (vendor
0x0bda product 0x8176) that gave me this "timeout waiting for checksum
report" message. Retrying didn't help, but plugging the dongle out and
then back in did. After powercycling the machine, I had to replug it
again. Once replugged, the dongle seems to work fine (I rebuilt kernel
and some ports via NFS over it thus far).

This suggests that the driver (or more generic part of the USB stack)
does not initialize something correctly, while full plug-and-play thing
does it. Any ideas?

/danfe

[Hans Petter Selasky]

On 02/10/14 13:21, Alexey Dokuchaev wrote:
> On Tue, Oct 15, 2013 at 11:13:56PM -0700, Rui Paulo wrote:
>> On 8 Oct 2013, at 10:41, Julian H. Stacey <j...@berklix.com> wrote:
>>> I too am seeing
>>> urtwn0: timeout waiting for checksum report
>>
>> Sorry, this is a know problem that I haven't been able to figure out...
>> It probably exists in the OpenBSD driver as well. Usually retrying works.
>
> To augment this a bit: I also came across one of these dongles (vendor
> 0x0bda product 0x8176) that gave me this "timeout waiting for checksum
> report" message. Retrying didn't help, but plugging the dongle out and
> then back in did. After powercycling the machine, I had to replug it
> again. Once replugged, the dongle seems to work fine (I rebuilt kernel
> and some ports via NFS over it thus far).
>
> This suggests that the driver (or more generic part of the USB stack)
> does not initialize something correctly, while full plug-and-play thing
> does it. Any ideas?
>

> ./danfe

Hi,

Looking at output from "usbdump -i usbusX -f Y" might give you some
clues. Else have you tried "usbconfig -d X.Y reset".

--HPS

[Alexey Dokuchaev]

On Mon, Feb 10, 2014 at 01:25:06PM +0100, Hans Petter Selasky wrote:
> On 02/10/14 13:21, Alexey Dokuchaev wrote:
> >To augment this a bit: I also came across one of these dongles (vendor
> >0x0bda product 0x8176) that gave me this "timeout waiting for checksum
> >report" message. Retrying didn't help, but plugging the dongle out and
> >then back in did. After powercycling the machine, I had to replug it
> >again. Once replugged, the dongle seems to work fine (I rebuilt kernel
> >and some ports via NFS over it thus far).
>

> Looking at output from "usbdump -i usbusX -f Y" might give you some clues.
> Else have you tried "usbconfig -d X.Y reset".

Hmm; I've added if_urtwn_load="YES" and some ifconfig...="WPA DHCP" lines
to rc.conf and surprisingly it came up OK after reboot. usbdump is full
of these lines (timestamps trimmed):

usbus0.3 SUBM-BULK-EP=00000081,SPD=HIGH,NFR=1,SLEN=0,IVAL=0
usbus0.3 DONE-BULK-EP=00000081,SPD=HIGH,NFR=1,SLEN=384,IVAL=0,ERR=0
^^^ sometimes 256

If I notice "checksum timeout" situation again, I'll post an update; thank
you for the tips.

/danfe

[Kevin Lo]

On 2014/02/10 20:21, Alexey Dokuchaev wrote:
> On Tue, Oct 15, 2013 at 11:13:56PM -0700, Rui Paulo wrote:
>> On 8 Oct 2013, at 10:41, Julian H. Stacey <j...@berklix.com> wrote:
>>> I too am seeing
>>> urtwn0: timeout waiting for checksum report
>> Sorry, this is a know problem that I haven't been able to figure out...
>> It probably exists in the OpenBSD driver as well. Usually retrying works.
> To augment this a bit: I also came across one of these dongles (vendor
> 0x0bda product 0x8176) that gave me this "timeout waiting for checksum
> report" message. Retrying didn't help, but plugging the dongle out and
> then back in did. After powercycling the machine, I had to replug it
> again. Once replugged, the dongle seems to work fine (I rebuilt kernel
> and some ports via NFS over it thus far).
>
> This suggests that the driver (or more generic part of the USB stack)
> does not initialize something correctly, while full plug-and-play thing
> does it. Any ideas?

We have to reset the bit of the R92C_MCUFWDL associated with checksum
report
before writing firmware. Could you try this patch? Thanks.

Index: sys/dev/usb/wlan/if_urtwn.c
===================================================================
--- sys/dev/usb/wlan/if_urtwn.c (revision 262971)
+++ sys/dev/usb/wlan/if_urtwn.c (working copy)
@@ -2071,6 +2071,10 @@ urtwn_load_firmware(struct urtwn_softc *sc)
urtwn_write_1(sc, R92C_MCUFWDL + 2,
urtwn_read_1(sc, R92C_MCUFWDL + 2) & ~0x08);

+ /* Reset the FWDL checksum. */
+ urtwn_write_1(sc, R92C_MCUFWDL,
+ urtwn_read_1(sc, R92C_MCUFWDL) | R92C_MCUFWDL_CHKSUM_RPT);
+
for (page = 0; len > 0; page++) {
mlen = min(len, R92C_FW_PAGE_SIZE);
error = urtwn_fw_loadpage(sc, page, ptr, mlen);

[Alexey Dokuchaev]

On Mon, Mar 10, 2014 at 03:41:16PM +0800, Kevin Lo wrote:
> On 2014/02/10 20:21, Alexey Dokuchaev wrote:
> >To augment this a bit: I also came across one of these dongles (vendor
> >0x0bda product 0x8176) that gave me this "timeout waiting for checksum
> >report" message. Retrying didn't help, but plugging the dongle out and
> >then back in did. After powercycling the machine, I had to replug it
> >again. Once replugged, the dongle seems to work fine (I rebuilt kernel
> >and some ports via NFS over it thus far).
> >
> >This suggests that the driver (or more generic part of the USB stack)
> >does not initialize something correctly, while full plug-and-play thing
> >does it. Any ideas?
>
> We have to reset the bit of the R92C_MCUFWDL associated with checksum report
> before writing firmware. Could you try this patch? Thanks.

Shit. I'd like to help, but no longer have access to the dongle. If I find
anything similar (or find a way to get access to original dongle remotely),
I'll let you know. :(

Thanks for working on these things Kevin, I appreciate it.

/danfe

[Kevin Lo]

On 2014/03/10 15:47, Alexey Dokuchaev wrote:
> On Mon, Mar 10, 2014 at 03:41:16PM +0800, Kevin Lo wrote:
>> On 2014/02/10 20:21, Alexey Dokuchaev wrote:
>>> To augment this a bit: I also came across one of these dongles (vendor
>>> 0x0bda product 0x8176) that gave me this "timeout waiting for checksum
>>> report" message. Retrying didn't help, but plugging the dongle out and
>>> then back in did. After powercycling the machine, I had to replug it
>>> again. Once replugged, the dongle seems to work fine (I rebuilt kernel
>>> and some ports via NFS over it thus far).
>>>
>>> This suggests that the driver (or more generic part of the USB stack)
>>> does not initialize something correctly, while full plug-and-play thing
>>> does it. Any ideas?
>> We have to reset the bit of the R92C_MCUFWDL associated with checksum report
>> before writing firmware. Could you try this patch? Thanks.
> Shit. I'd like to help, but no longer have access to the dongle. If I find
> anything similar (or find a way to get access to original dongle remotely),
> I'll let you know. :(

No worries. I committed it as r263154. Hope this problem get fixed. :-)

>
> Thanks for working on these things Kevin, I appreciate it.
>

> ./danfe

Kevin

[Kevin Lo]

On 2013/12/20 15:31, Alexey Dokuchaev wrote:
> On Fri, Dec 20, 2013 at 01:35:37PM +0800, Kevin Lo wrote:
>> I'd like to port it after finishing RT5373 driver support. :-)
> Nice, looking forward to it. :)

As promised, I have committed support for the RTL8188EUS chipset.
The driver is a work in progress. The connection is slow but it's better
than nothing. :-)

>
>> Here's a site you could use for info about your wireless device:
>> http://wikidevi.com/wiki/TP-LINK_TL-WN723N_v3
> Thank you Kevin.
>

> ./danfe

Kevin