netdev - 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-next>] [day] [month] [year] [list]

Message-Id: <200612020316.50965.flamingice@sourmilk.net>
Date:	Sat, 2 Dec 2006 03:16:46 -0500
From:	Michael Wu <flamingice@...rmilk.net>
To:	Daniel Drake <dsd@...too.org>
Cc:	Ulrich Kunitz <kune@...ne-taler.de>, netdev@...r.kernel.org,
	John Linville <linville@...driver.com>,
	"Luis Rodriguez" <mcgrof@...il.com>
Subject: zd1211 ported to Devicescape stack

Hi,
	I have finished a port of the zd1211 driver to the Devicescape 802.11 stack. 
Due to the size of the patch, the patch that copies the zd1211 directory to 
the d80211 directory has been omitted, but can be found at my git repo. 
(git://git.kernel.org/pub/scm/linux/kernel/git/mwu/d80211-drivers.git up) The 
two other patches relevant to porting the driver are bzip2ed and attached due 
to size concerns.

This port works fairly well in STA mode, with adhoc and monitor modes to come 
in the future. I tried to minimize changes to the structure of the driver and 
code whenever possible to make it easier to port patches from the softmac 
based zd1211 driver to this driver. However:

	- 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.
	-Because d80211 does not have complete regulatory domains support yet, the 
associated code was trimmed to the bare minimum of reading the region code. 
It should be a trivial patch to add regulatory domains support once the 
infrastructure is in place in d80211.
	- 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.
	- 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.

I will push this to wireless-dev soon if there are no major problems.

Thanks,
-Michael Wu

Download attachment "zd1211-kconfig.bz2" of type "application/x-bzip2" (1229 bytes)

Download attachment "zd1211-port-to-d80211.bz2" of type "application/x-bzip2" (13210 bytes)

Content of type "application/pgp-signature" skipped