netdev - Re: zd1211 ported to Devicescape stack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 02 Dec 2006 10:58:13 -0500
From:	Daniel Drake <dsd@...too.org>
To:	Michael Wu <flamingice@...rmilk.net>
CC:	Ulrich Kunitz <kune@...ne-taler.de>, netdev@...r.kernel.org,
	John Linville <linville@...driver.com>,
	Luis Rodriguez <mcgrof@...il.com>
Subject: Re: zd1211 ported to Devicescape stack

Michael Wu wrote:
> Hi,
> 	I have finished a port of the zd1211 driver to the Devicescape 802.11 stack. 

Yeah!! thanks so much for doing this.

Are you willing to maintain this in terms of porting upcoming patches to 
it? I think I also speak for Ulrich when I say that at the moment we are 
more concerned about getting our work into mainline and don't have time 
to maintain a ported driver, but we will be happy to switch immediately 
as soon as devicescape is declared ready for mainline inclusion.

> 	- The original driver does not seem to check if a frame has been successfully 
> TXed (as in RXed an ACK), so the port does not properly report to the stack 
> whether or not a TX succeeded.

Indeed, the situation is that silence means transmission succeeded, and 
we get a retry_failed interrupt if it didn't.

> 	- d80211 doesn't tell us the size of the next fragment, so that part of the 
> hardware TX header isn't set anymore. This might be fixed in the future.

Even though ieee80211 appeared to have the infrastructure to do so, I 
don't think it was ever passing us multiple fragments. So this is no big 
deal.

> 	- The LED link status isn't too reliable - I haven't found a way to reliably 
> tell if the upper layer thinks it is associated, and I don't know how to use 
> the LED api. Not too worried about this issue though.

Watch out, the single most common bug report for zd1211rw (vs vendor 
driver) was that the LED didn't blink until recently :)

Thanks!
Daniel

-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html