ieee80211 patches

ieee80211 patches

[Jiri Benc]

Our patches against latest ieee80211 branch of netdev tree can be found at
http://forge.novell.com/modules/xfmod/cvs/cvsbrowse.php/ieee80211/patches-upstream/
(it is possible to download a tarball from this link too).

For CVS checkout enter
cvs -z3 -d:ext:anonymous@forgecvs1.novell.com:/cvsroot/ieee80211 co patches-upstream

Patches have to be applied in order specified in 'series' file (e. g.
using quilt).

Jeff, should we also post those patches to netdev?

 Jiri Benc and Jirka Bohac


-- 
Jiri Benc
SUSE Labs

Re: ieee80211 patches

[Michael Wu]

On Thursday 25 August 2005 13:31, Jiri Benc wrote:
> Our patches against latest ieee80211 branch can be found at
> http://kernel.org/pub/linux/kernel/people/jbenc/
>
I hope to submit the adm8211 driver for review soon, but there's a bunch of 
code in the driver which probably belong in the ieee80211 code:

- Duplicate frame removal
- Definitions for all management payloads
- SIOCSIWENCODEEXT and SIOCGIWENCODEEXT
- AVS capture header in monitor mode
- Software Scanning
- Software Authentication & Association

Does that sound okay? I will start submitting patches to add those things if 
they should be in the ieee80211 code.

Thanks,
-Michael Wu

Re: ieee80211 patches

[Stefan Rompf]

Hi,

Am Freitag 26 August 2005 02:49 schrieb Michael Wu:

> I hope to submit the adm8211 driver for review soon, but there's a bunch of
> code in the driver which probably belong in the ieee80211 code:
[...]
> - AVS capture header in monitor mode

there has been a discussion about AVS or radiotap header on the ipw list that 
resulted in the inclusion of radiotap definitions in James' latest patches 
for ieee80211. Radiotap requires a libpcap upgrade, but can be extended 
easier. I'd like all linux wireless drivers to move to radiotap for statistic 
data so that userspace has just one format to parse, and a new driver would 
be a perfect target to begin.

Stefan

Re: ieee80211 patches

[Jiri Benc]

On Thu, 25 Aug 2005 20:49:52 -0400, Michael Wu wrote:
> I hope to submit the adm8211 driver for review soon, but there's a bunch of 
> code in the driver which probably belong in the ieee80211 code:
> 
> - Duplicate frame removal
> - Definitions for all management payloads
> - SIOCSIWENCODEEXT and SIOCGIWENCODEEXT
> - AVS capture header in monitor mode
> - Software Scanning
> - Software Authentication & Association
> 
> Does that sound okay? I will start submitting patches to add those things if 
> they should be in the ieee80211 code.

Sounds great. Could you post a pointer to the project?

Btw, Andrea Merello has a code for some of these features in his
rtl8180-sa2400 project (http://sourceforge.net/projects/rtl8180-sa2400)
too - we are trying to subsequently include them.

Thanks,

-- 
Jiri Benc
SUSE Labs

Re: ieee80211 patches

[Michael Wu]

On Friday 26 August 2005 05:04, Stefan Rompf wrote:
> > - AVS capture header in monitor mode
>
> there has been a discussion about AVS or radiotap header on the ipw list
> that resulted in the inclusion of radiotap definitions in James' latest
> patches for ieee80211. Radiotap requires a libpcap upgrade, but can be
> extended easier. I'd like all linux wireless drivers to move to radiotap
> for statistic data so that userspace has just one format to parse, and a
> new driver would be a perfect target to begin.
>
Sounds like everyone agrees that radiotap is a superior header. I will remove 
AVS support and add radiotap support (if additional code is needed) once 
radiotap code is merged in ieee80211.

Thanks,
-Michael Wu

Re: ieee80211 patches

[Michael Wu]

On Friday 26 August 2005 08:08, Jiri Benc wrote:
> On Thu, 25 Aug 2005 20:49:52 -0400, Michael Wu wrote:
> > I hope to submit the adm8211 driver for review soon, but there's a bunch
> > of code in the driver which probably belong in the ieee80211 code:
> >
> > - Duplicate frame removal
> > - Definitions for all management payloads
> > - SIOCSIWENCODEEXT and SIOCGIWENCODEEXT
> > - AVS capture header in monitor mode
> > - Software Scanning
> > - Software Authentication & Association
> >
> > Does that sound okay? I will start submitting patches to add those things
> > if they should be in the ieee80211 code.
>
> Sounds great. Could you post a pointer to the project?
>
http://aluminum.sourmilk.net/adm8211/index.php?path=netdev/

> Btw, Andrea Merello has a code for some of these features in his
> rtl8180-sa2400 project (http://sourceforge.net/projects/rtl8180-sa2400)
> too - we are trying to subsequently include them.
>
Hmm..

- adm8211 supports shared key authentication, rtl8180-sa2400 only supports 
open authentication. (which is kinda okay when you consider that 802.11i 
doesn't use shared key)
- Both drivers do not support LEAP authentication.
- adm8211 supports WE18/WPA (partly via SIWGENIE, it doesn't generate WPA/RSN 
IEs itself)
- rtl8180-sa2400 supports a really simple master mode. (should something like 
hostapd be used instead for master mode?)
- rtl8180-sa2400 supports sending probe responses. adm8211 lets the hardware 
do it, though newer adm8211 cards can be told to hand it off to the software.
- rtl8180-sa2400 creates a completely random bssid in adhoc. adm8211 keeps the 
first 3 octets from the MAC addr.
- adm8211 supports sending & handling deauthentication and disassociation 
frames. I did not see definitions for those frames, so I assume there's no 
support there.
- adm8211 needs many hooks in scanning/authentication/association to set 
BSSID/SSID/AID/etc. in hardware.
- rtl8180-sa2400 doesn't seem to convert to little endian in a number of 
places. (not really major..)

-Michael Wu

Re: ieee80211 patches

[Michael Wu]

On Friday 26 August 2005 12:13, Jiri Benc wrote:
> You mentioned problem with hooks in scanning/association/etc. Probably
> everybody involved in this discussion knows it but I think it is worth
> saying it: This is one of the most important things in a new ieee80211
> layer. Unfortunately, it seems that every driver developer concentrates
> on the aspects of his device (this include ieee80211 layer from ipw as
> well as from rtl8180). But every device (or more precisely firmware)
> provides different set of features - some takes care of almost
> everything, other can do basic things only. So the amount of work that
> needs to be done in the ieee80211 layer is different for different
> devices. The layer has to be generic. It has to cope e.g. with
> authentication/association performed fully by itself as well as with
> auth/assoc performed automatically by the device, etc.
>
> I'm convinced this is the first goal we have to reach before we start to
> implement WPA, QoS and so.
Right now, the adm8211 driver uses a number of specific hooks in its own 
ieee80211 station management code such as:

set_bssid
set_ssid
set_channel
set_interval
set_beacon

Though with enough of these hooks, many devices can be supported, I think 
generic hooks like these would work best to support a wide range of hardware 
that use softmac:

pre_scan
set_channel
pre_associate
link_change
start_ibss
join_ibss

Then for the devices that do more in the firmware, adding callbacks like:

hw_scan
hw_associate
hw_start_ibss

would indicate to the ieee80211 layer that the hardware is capable of handling 
those things itself.

The driver should be able to find all the info needed to configure the 
hardware in ieee80211_device so only that needs to be passed to the hooks.

A good portion of WPA can be implemented right now by implementing the 
encodeext ioctls and generalizing ieee80211_security to support more than 
just WEP. adm8211 doesn't have support for non-wep encryption yet, so WPA 
works without ieee80211_security support.

Sound good?

-Michael Wu