[RFC] acx100 inclusion in mainline; generic 802.11 stack

[RFC] acx100 inclusion in mainline; generic 802.11 stack

[Denis Vlasenko]

Hi all,

It looks like acx100 approaches state when we can consider it's inclusion
into mainline kernel.

Some background information: acx100 and acx111 hardware is a bit like
Atheros and possibly prism54 "softmac": it handles mostly low-level
rx/tx stuff, leaving 802.11 stack implementation up to OS
(which is good. To have largish potentially buggy binary-only firmware
to cope with is a nightmare).

I think what acx100 devel is working on can be best described as
"yet another 802.11 stack implementation". This is not ok.

I think we definitely need generic 802.11 stack, with individual drivers
providing only needed callbacks, just like it is done for wired eth drivers.

I think 'senior' network guys are in position to decide upon which 
of currently available 802.11 stacks we should continue to work.
(Atheros has one, said to be derived from BSD, is there any others?)

Give us some guidance please...
--
vda

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Jeff Garzik]

Denis Vlasenko wrote:
> I think 'senior' network guys are in position to decide upon which 
> of currently available 802.11 stacks we should continue to work.
> (Atheros has one, said to be derived from BSD, is there any others?)


Already have.  Start with the code in wireless-2.6 -- HostAP -- and use 
DaveM's 802.11 stack template as a model for actually integrating 802.11 
very tightly with the rest of the net stack.

http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2

	Jeff

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 1624 bytes --]

On Tuesday 31 August 2004 21:21, Jeff Garzik wrote:
JG> Denis Vlasenko wrote:
JG> > I think 'senior' network guys are in position to decide upon which
JG> > of currently available 802.11 stacks we should continue to work.
JG> > (Atheros has one, said to be derived from BSD, is there any others?)
JG>
JG>
JG> Already have.  Start with the code in wireless-2.6 -- HostAP -- and use
JG> DaveM's 802.11 stack template as a model for actually integrating 802.11
JG> very tightly with the rest of the net stack.
JG>
JG>
 http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p8
0211.tar.bz2 JG>
JG>  Jeff

This stack raises many questions.

The very idea to implement generic softmac is pretty good.

So, first questions:

- it defines structures that was present in Jean's wireless extensions. So, 
will it replace Jean's wireless extensions, merge with it, or some other 
relationship? Partually, I don't like to see definitions for .11 header and 
field constants in 2 includes.

- QoS stuff is not defined. I suppose recent cards will all support WME and/or 
TGe. It is easy to add "QoS control" field to header and new frame types, but 
it is harder to formally define how PHY should handle it. And, TGe is big 
story on itself, with all its HCCA, block ack, etc. I also think that QoS, as 
it is defined in TGe, required driver to have several tx queues and 
start/stop them separately. Is anyone working on it? I'll be glad to join.

- Security is not up-to date either. We need .1x, EAS, TKIP etc. This need to 
be done for modern cards to use this infrastructure.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Luis R. Rodriguez]

On Tue, Aug 31, 2004 at 10:14:38PM +0300, Vladimir Kondratiev wrote:
> On Tuesday 31 August 2004 21:21, Jeff Garzik wrote:
> JG> Denis Vlasenko wrote:
> JG> > I think 'senior' network guys are in position to decide upon which
> JG> > of currently available 802.11 stacks we should continue to work.
> JG> > (Atheros has one, said to be derived from BSD, is there any others?)
> JG>
> JG>
> JG> Already have.  Start with the code in wireless-2.6 -- HostAP -- and use
> JG> DaveM's 802.11 stack template as a model for actually integrating 802.11
> JG> very tightly with the rest of the net stack.
> JG>
> JG>
>  http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p8
> 0211.tar.bz2 JG>
> JG>  Jeff
> 
> This stack raises many questions.
> 
> The very idea to implement generic softmac is pretty good.
> 
> So, first questions:
> 
> - it defines structures that was present in Jean's wireless extensions. So, 
> will it replace Jean's wireless extensions, merge with it, or some other 
> relationship? Partually, I don't like to see definitions for .11 header and 
> field constants in 2 includes.
> 
> - QoS stuff is not defined. I suppose recent cards will all support WME and/or 
> TGe. It is easy to add "QoS control" field to header and new frame types, but 
> it is harder to formally define how PHY should handle it. And, TGe is big 
> story on itself, with all its HCCA, block ack, etc. I also think that QoS, as 
> it is defined in TGe, required driver to have several tx queues and 
> start/stop them separately. Is anyone working on it? I'll be glad to join.
> 
> - Security is not up-to date either. We need .1x, EAS, TKIP etc. This need to 
> be done for modern cards to use this infrastructure.

This is handled by hostap wpa_supplicant now, which is going to be part
of WE18. The question I think is whether somoene plans on re-doing it on
wireless-2.6, since as you mentioned it seems WE are being redone on
davem's patch.

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1.1: Type: text/plain, Size: 779 bytes --]

<skip>
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p80211.tar.bz2 
<skip>
LR> > - QoS stuff is not defined. I suppose recent cards will all support WME
 and/or LR> > TGe. It is easy to add "QoS control" field to header and new
 frame types, but LR> > it is harder to formally define how PHY should handle
 it. And, TGe is big LR> > story on itself, with all its HCCA, block ack,
 etc. I also think that QoS, as LR> > it is defined in TGe, required driver
 to have several tx queues and LR> > start/stop them separately. Is anyone
 working on it? I'll be glad to join. LR> >

I'd like to contribute easiest part of TGe, to start with something (against 
source mentioned above). I defined only frame formats and bits for fixed 
fields.

[-- Attachment #1.2: tge.patch --]
[-- Type: text/x-diff, Size: 3682 bytes --]

Index: if_80211.h
===================================================================
RCS file: /home/vkondra-l/cvsroot/p80211/if_80211.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 if_80211.h
--- if_80211.h	31 Aug 2004 20:32:16 -0000	1.1.1.1
+++ if_80211.h	31 Aug 2004 21:29:58 -0000
@@ -31,6 +31,27 @@
 	u8 addr4[ETH_ALEN];
 };
 
+struct ieee802_11_hdrq {
+	u16 frame_ctl;
+	u16 duration_id;
+	u8 addr1[ETH_ALEN];
+	u8 addr2[ETH_ALEN];
+	u8 addr3[ETH_ALEN];
+	u16 seq_ctl;
+	u16 qos_ctl;
+};
+
+struct ieee802_11_hdr4q {
+	u16 frame_ctl;
+	u16 duration_id;
+	u8 addr1[ETH_ALEN];
+	u8 addr2[ETH_ALEN];
+	u8 addr3[ETH_ALEN];
+	u16 seq_ctl;
+	u8 addr4[ETH_ALEN];
+	u16 qos_ctl;
+};
+
 /* Address field usage based upon setting of FROMDS/TODS bits:
  *
  * FROMDS	TODS	addr1	addr2	addr3	addr4
@@ -78,8 +99,11 @@
 #define IEEE802_11_STYPE_DISASSOC	0x00A0
 #define IEEE802_11_STYPE_AUTH		0x00B0
 #define IEEE802_11_STYPE_DEAUTH		0x00C0
+#define IEEE802_11_STYPE_ACTION		0x00D0
 
 /* control */
+#define IEEE802_11_STYPE_BACK_REQ	0x0080
+#define IEEE802_11_STYPE_BACK		0x0090
 #define IEEE802_11_STYPE_PSPOLL		0x00A0
 #define IEEE802_11_STYPE_RTS		0x00B0
 #define IEEE802_11_STYPE_CTS		0x00C0
@@ -96,11 +120,51 @@
 #define IEEE802_11_STYPE_CFACK		0x0050
 #define IEEE802_11_STYPE_CFPOLL		0x0060
 #define IEEE802_11_STYPE_CFACKPOLL	0x0070
+#define IEEE802_11_STYPE_QDATA		0x0080
+#define IEEE802_11_STYPE_QDATA_CFACK	0x0090
+#define IEEE802_11_STYPE_QDATA_CFPOLL	0x00A0
+#define IEEE802_11_STYPE_QDATA_CFACKPOLL	0x00B0
+#define IEEE802_11_STYPE_QNULLFUNC	0x00C0
+#define IEEE802_11_STYPE_QCFACK		0x00D0
+#define IEEE802_11_STYPE_QCFPOLL		0x00E0
+#define IEEE802_11_STYPE_QCFACKPOLL	0x00F0
 
 #define IEEE802_11_SCTL_FRAG		0x000F
 #define IEEE802_11_SCTL_SEQ		0xFFF0
 #define IEEE802_11_SCTL_SEQ_SHIFT	4
 
+/** QOS control field bits usage
+ *  Frame               0..3  4     5..6        7     8..15
+ * 
+ * QoS (+)CF-Poll       TID   EOSP  Ack_policy  rsrv  TXOP limit
+ * sent by HC
+ * 
+ * QoS Data, QoS Null,  TID   EOSP  Ack_policy  rsrv  QAP PS buffer size
+ * QoS CF-Ack,
+ * QoS Data + CF-Ack
+ * sent by HC
+ * 
+ * QoS Data sent by     TID   0     Ack_policy  rsrv  TXOP duration requested
+ * non-AP QSTA          TID   1     Ack_policy  rsrv  Queue size
+ * 
+ */
+#define IEEE802_11_QCTL_FRAG		0x000F
+#define IEEE802_11_QCTL_EOSP		0x0010
+#define IEEE802_11_QCTL_ACK 		0x0060
+#define IEEE802_11_QCTL_VAL 		0xFF00
+
+/* bits for ack policy */
+#define IEEE802_11_QCTL_ACK_NORM 		0x0000  /* normal Ack      */
+#define IEEE802_11_QCTL_ACK_NO   		0x0020  /* No ack          */
+#define IEEE802_11_QCTL_ACK_NEXP 		0x0040  /* No explicit Ack */
+#define IEEE802_11_QCTL_ACK_BLK  		0x0060  /* Block Ack       */
+
+/* bits for QAP PS buffer size */
+#define IEEE802_11_QCTL_PSBUF_PRESENT 		0x0200  /* next fields present    */
+#define IEEE802_11_QCTL_PSBUF_HI_AC   		0x0C00  /* highest AC buffered    */
+#define IEEE802_11_QCTL_PSBUF_BUF     		0xF000  /* total buffered payload */
+
+
 struct ieee802_11_snap {
 	u8	dsap;
 	u8	ssap;
@@ -119,6 +183,14 @@
 #define IEEE802_11_TLV_TYPE_TIM		5
 #define IEEE802_11_TLV_TYPE_IBSSPARMS	6
 #define IEEE802_11_TLV_TYPE_COUNTRY	7
+#define IEEE802_11_TLV_TYPE_QBSS_LOAD	11
+#define IEEE802_11_TLV_TYPE_EDCA	12
+#define IEEE802_11_TLV_TYPE_TSPEC	13
+#define IEEE802_11_TLV_TYPE_TCLAS	14
+#define IEEE802_11_TLV_TYPE_SCHED	15
+#define IEEE802_11_TLV_TYPE_TS_DELAY	43
+#define IEEE802_11_TLV_TYPE_TC_PROC	44
+#define IEEE802_11_TLV_TYPE_QOS_CAP	46
 #define IEEE802_11_TLV_TYPE_XRATES	50
 
 #define IEEE802_11_MAX_RATES	8

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Jouni Malinen]

On Tue, Aug 31, 2004 at 05:37:19PM -0400, Luis R. Rodriguez wrote:
> On Tue, Aug 31, 2004 at 10:14:38PM +0300, Vladimir Kondratiev wrote:
> > - Security is not up-to date either. We need .1x, EAS, TKIP etc. This need to 
> > be done for modern cards to use this infrastructure.
> 
> This is handled by hostap wpa_supplicant now, which is going to be part
> of WE18. The question I think is whether somoene plans on re-doing it on
> wireless-2.6, since as you mentioned it seems WE are being redone on
> davem's patch.

This sounds somewhat confusing.. As far as WPA and IEEE 802.11i
(RSN/WPA2) are concerned, there are number of different components
involved.

One part is in IEEE 802.11 data frame handling (TKIP, CCMP). This is
implemented, e.g., in the current Host AP RX/TX paths more or less
completely. The current implementation is still hardcoded to do this in
software, so it would need to be extended to support offloading
encryption to the wlan card since many of the modern cards have hardware
(or combination of hardware/firmware) implementation of TKIP and CCMP.
In addition, IEEE 802.11e will add some small changes to TKIP/CCMP
processing; Host AP code has places for this for TX (mainly, setting
priority value in the header). RX needs some more work because of
possible reordering of packets with different priorities. This all lives
in the generic 802.11 stack of the kernel.

In addition to data encryption, IEEE 802.11i defines key management
protocol (4-Way/PTK handshake, 2-Way/Group Key handshake) and
optimizations for full IEEE 802.1X authentication (PMKSA caching,
pre-authentication). IEEE 802.1X and EAP authentication is on similar
level. All these are done using EAPOL packet (own ethertype; one for
EAPOL and one for pre-authentication). This could be done in kernel, but
I don't see much point in that and have thus implemented these in user
space. wpa_supplicant includes the Supplicant part both for IEEE 802.1X
and IEEE 802.11i key handshakes. hostapd includes the Authenticator part
for the same functionality.

Being able to keep authentication and key management separated from the
data encryption. There needs to be an interface for configuring and
getting event information. I would say this can be considered as
separate design area. Currently, hostapd and wpa_supplicant are using
combination of ioctls (WE and private, depending on the driver) for user
space -> kernel configuration (e.g., encryption keys), wireless events
(netlink) for getting event information (association/encryption
error/etc.), network interfaces with or without IEEE 802.11 headers
(e.g., hostapd includes IEEE 802.11 headers for management frames in a
separate interface and wpa_supplicant uses just Ethernet header and
normal data interface to get the two special ethertypes).

This communication interface can be replaced with something different,
if desired, without affecting the other parts of the implementation (the
encryption of data frames itself or the authentication/key management
protocols).

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 852 bytes --]

Jeff,

On Tuesday 31 August 2004 21:21, Jeff Garzik wrote:
JG> Denis Vlasenko wrote:
JG> > I think 'senior' network guys are in position to decide upon which
JG> > of currently available 802.11 stacks we should continue to work.
JG> > (Atheros has one, said to be derived from BSD, is there any others?)
JG>
JG>
JG> Already have.  Start with the code in wireless-2.6 -- HostAP -- and use
JG> DaveM's 802.11 stack template as a model for actually integrating 802.11
JG> very tightly with the rest of the net stack.
JG>
JG>
 http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p8
0211.tar.bz2 

Is this stack the main one that is going to be used? I.e. if I am working on 
driver for next generation .11 card - should I try to use it, request/submitt 
missing features etc.? Or should I use wireless extensions?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Jeff Garzik]

Vladimir Kondratiev wrote:
> Jeff,
> 
> On Tuesday 31 August 2004 21:21, Jeff Garzik wrote:
> JG> Denis Vlasenko wrote:
> JG> > I think 'senior' network guys are in position to decide upon which
> JG> > of currently available 802.11 stacks we should continue to work.
> JG> > (Atheros has one, said to be derived from BSD, is there any others?)
> JG>
> JG>
> JG> Already have.  Start with the code in wireless-2.6 -- HostAP -- and use
> JG> DaveM's 802.11 stack template as a model for actually integrating 802.11
> JG> very tightly with the rest of the net stack.
> JG>
> JG>
>  http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p8
> 0211.tar.bz2 
> 
> Is this stack the main one that is going to be used? I.e. if I am working on 
> driver for next generation .11 card - should I try to use it, request/submitt 
> missing features etc.? Or should I use wireless extensions?

DaveM's code is a template for how a wireless stack would look when 
properly and fully integrated into the net core.

Although JeanT and I disagree about this, I am less interested in 
backwards compatibility than I am about making wireless a "first class 
citizen" in the kernel.  As I have proven with kcompat 
(http://sf.net/projects/gkernel/) you can be backwards compatible while 
still evolving the current kernel driver API to meet current design needs.

	Jeff




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

Is anyone working on this stack? I asked Dave, he is hot working on it.
Or is this code dead?

On Thursday 02 September 2004 23:33, Jeff Garzik wrote:
JG> Vladimir Kondratiev wrote:
JG> > Jeff,
JG> >
JG> > On Tuesday 31 August 2004 21:21, Jeff Garzik wrote:
JG> > JG> Denis Vlasenko wrote:
JG> > JG> > I think 'senior' network guys are in position to decide upon
 which JG> > JG> > of currently available 802.11 stacks we should continue to
 work. JG> > JG> > (Atheros has one, said to be derived from BSD, is there
 any others?) JG> > JG>
JG> > JG>
JG> > JG> Already have.  Start with the code in wireless-2.6 -- HostAP -- and
 use JG> > JG> DaveM's 802.11 stack template as a model for actually
 integrating 802.11 JG> > JG> very tightly with the rest of the net stack.
JG> > JG>
JG> > JG>
JG> > 
 http://www.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.6/davem-p8
 JG> > 0211.tar.bz2
JG> >
JG> > Is this stack the main one that is going to be used? I.e. if I am
 working on JG> > driver for next generation .11 card - should I try to use
 it, request/submitt JG> > missing features etc.? Or should I use wireless
 extensions?
JG>
JG> DaveM's code is a template for how a wireless stack would look when
JG> properly and fully integrated into the net core.
JG>
JG> Although JeanT and I disagree about this, I am less interested in
JG> backwards compatibility than I am about making wireless a "first class
JG> citizen" in the kernel.  As I have proven with kcompat
JG> (http://sf.net/projects/gkernel/) you can be backwards compatible while
JG> still evolving the current kernel driver API to meet current design
 needs. JG>
JG> 	Jeff
JG>
JG>
JG>
JG>

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Jeff Garzik]

Vladimir Kondratiev wrote:
> Is anyone working on this stack? I asked Dave, he is hot working on it.
> Or is this code dead?


Nobody is actively working on that stack AFAIK.

	Jeff




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Sam Leffler]

On Aug 31, 2004, at 11:11 AM, Denis Vlasenko wrote:

> Hi all,
>
> It looks like acx100 approaches state when we can consider it's 
> inclusion
> into mainline kernel.
>
> Some background information: acx100 and acx111 hardware is a bit like
> Atheros and possibly prism54 "softmac": it handles mostly low-level
> rx/tx stuff, leaving 802.11 stack implementation up to OS
> (which is good. To have largish potentially buggy binary-only firmware
> to cope with is a nightmare).
>
> I think what acx100 devel is working on can be best described as
> "yet another 802.11 stack implementation". This is not ok.
>
> I think we definitely need generic 802.11 stack, with individual 
> drivers
> providing only needed callbacks, just like it is done for wired eth 
> drivers.
>
> I think 'senior' network guys are in position to decide upon which
> of currently available 802.11 stacks we should continue to work.
> (Atheros has one, said to be derived from BSD, is there any others?)

To correct this oft-repeated misinformation: "Atheros has one" is 
wrong.  There is a freely available device-independent 802.11 protocol 
stack that is dual BSD/GPL licensed.  The only relationship between 
this code and Atheros is  that the madwifi project uses it to support 
Atheros hardware under Linux.  Atheros holds no copyrights on any of 
the net80211 code.

As to it being derived from BSD, that is correct but misleading.  The 
1st generation of this code was done for netbsd but the current code is 
very different and has been developed almost exclusively in Linux for 
over a year (though I'm now trying to find time to backport to 
FreeBSD).

The net80211 code is actively used in netbsd to support 6+ drivers and 
a similar number in freebsd.  There is a fairly complete implementation 
of the 802.11 protocols (fragmentation isn't there but will be soon) 
including 11g, WPA/11i, WME and WSM (coming soon).  WPA/802.11i 
supplicant support using wpa_supplicant has been available for a while 
and a hostapd-based authenticator will hit CVS shortly.  The management 
API for Linux is based on wireless extensions (WE is insufficient so 
like everyone else you'll find lots of private ioctls).

I've suggested this code as a good starting point for a "generic 802.11 
stack" but received only misinformed responses.  Folks who are unaware 
of the work should take a look at it.

	Sam

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

Sam,

could you please provide URL where this code is hosted? I know it only as part 
of madwifi. 

Vladimir

SL> I've suggested this code as a good starting point for a "generic 802.11
SL> stack" but received only misinformed responses.  Folks who are unaware
SL> of the work should take a look at it.
SL>
SL>  Sam

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Sam Leffler]

On Sep 6, 2004, at 11:57 AM, Vladimir Kondratiev wrote:

> Sam,
>
> could you please provide URL where this code is hosted? I know it only 
> as part
> of madwifi.

The madwifi project is hosted at sourceforge 
http;//sourceforge.net/projects/madwifi. Source code is currently 
available only via cvs (but there's a web interface that you can reach 
through the above url).

	Sam




-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]

I know about madwifi. I wondering whether there is URL for net80211, or it 
exist only as part of madwifi.
Thanks, Vladimir
On Monday 06 September 2004 22:30, Sam Leffler wrote:
SL> On Sep 6, 2004, at 11:57 AM, Vladimir Kondratiev wrote:
SL>
SL> > Sam,
SL> >
SL> > could you please provide URL where this code is hosted? I know it only
SL> > as part
SL> > of madwifi.
SL>
SL> The madwifi project is hosted at sourceforge
SL> http;//sourceforge.net/projects/madwifi. Source code is currently
SL> available only via cvs (but there's a web interface that you can reach
SL> through the above url).
SL>
SL>  Sam

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Sam Leffler]

On Monday 06 September 2004 01:09 pm, Vladimir Kondratiev wrote:
> I know about madwifi. I wondering whether there is URL for net80211, or it
> exist only as part of madwifi.

It only exists as part of other systems (madwifi, netbsd, freebsd, etc.)

	Sam


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[David S. Miller]

On Mon, 6 Sep 2004 11:13:31 -0700
Sam Leffler <sam@errno.com> wrote:

> I've suggested this code as a good starting point for a "generic 802.11 
> stack" but received only misinformed responses.

Sam, I've told you multiple times why your stack isn't a good
starting point.  It isn't implemented as a true network stack,
like IPV4, Appletalk, etc.  Instead it's a gross input packet
hooked packet eater thing that's an ugly wart bolted onto the
side of the driver API.

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Sam Leffler]

On Monday 06 September 2004 06:23 pm, David S. Miller wrote:
> On Mon, 6 Sep 2004 11:13:31 -0700
>
> Sam Leffler <sam@errno.com> wrote:
> > I've suggested this code as a good starting point for a "generic 802.11
> > stack" but received only misinformed responses.
>
> Sam, I've told you multiple times why your stack isn't a good
> starting point.  It isn't implemented as a true network stack,
> like IPV4, Appletalk, etc.  Instead it's a gross input packet
> hooked packet eater thing that's an ugly wart bolted onto the
> side of the driver API.

Actually, this is the first time you've said anything to me about this code.  
We corresponded intensely for about a week 2+ years ago after which you 
declared you now knew how to "write an 802.11 stack right" and were going to 
do it that weekend.  I waited but it seems the sum total result was the shell 
of code that Jeff referenced in a previous note.

Perhaps you can point me at a description of what a "true network stack" means 
to you.  I'm guessing this has to do with your wanting queues inserted at 
various places instead of direct handoffs.  Regardless, I've never suggested 
the current code is suitable as-is but rather should be reshaped to suit the 
intended structure of the system.  There is a lot of hard-earned experience 
in the code that is independent of coding style and operational 
infrastructure.

Anyway, the point of my note was to correct a comment in the original posting 
and make folks aware that working code existed from which they could crib 
stuff.  Good luck finding someone to reimplement eveything according to your 
wishes.

	Sam


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[David S. Miller]

On Mon, 6 Sep 2004 21:32:49 -0700
Sam Leffler <sam@errno.com> wrote:

> Actually, this is the first time you've said anything to me about this code.  

I do remember telling you how much I was against this element of
your design.  At the time, you were not willing to rearchitect things
and you were in a sort-of bug-fix only mode.

> Perhaps you can point me at a description of what a "true network stack" means 
> to you.

It means passing the 802.11 protocol packets into the networking
just like any other type of packet, via netif_rx() or netif_receive_skb().
Creating an ETH_P_80211 protocol type and registering the stack via
dev_add_pack() just like any other real protocol layer does.

Then responses generated in that 802.11 stack need to feed packets back
out to the network via the normal and usual methods of transmitting
packets in the networking, namely dev_queue_xmit().

That is exactly what my shell protocol layer does, and it is exactly
how a real 802.11 soft stack should be implemented and operate.


-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

Dave,
I'd like to evaluate possibility to use your stack for real driver. 80211 have 
some specifics thus we need to answer following questions:

- some devices handles almost all MAC in firmware; some - handle control frame 
exchange in firmware, rest - on host; some use other separation of work 
between host and firmware. So, quite flexible mechanism to specify offloading 
of parts of .11 stack to firmware required. What is best way? 
netdev->features?

- there are cases when PHY information needed, to make decisions (like select 
AP from list), or for information purposes (sniffer). What is your vision how 
to do this? I.e. provide some standard PHY header before MAC header, out of 
band (use cb?)
I see the following info that may be interesting:
rate;modulation;preamble;TSF timer;RSSI;antenna;signal;noise;AGC. This list 
may vary from NIC to NIC.

- there is PHY level information that may be needed for Tx:
modulation;rate;retry policy and rates;Tx power;protection(RTS/CTS, CTS to 
self). Same question as above: how to provide it?

- there is some interesting information that may come from Tx status, like 
success indication, last rate, retry count, energy in channel after packet, 
actual backoff time.

- is it feasible to do rate scaling in generic way in stack? Or should it be 
done always in the driver?

- Since WME and TGe introduction, NICs will likely to have multiple Tx queues. 
It would be wise for driver to use multiple Tx queues and start/stop them 
separately, like have all functions netif_start_queue() etc. have additional 
parameter - queue number. Will it fit into your stack?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[David S. Miller]

On Tue, 7 Sep 2004 20:22:07 +0300
Vladimir Kondratiev <vkondra@mail.ru> wrote:

> I'd like to evaluate possibility to use your stack for real driver. 80211 have 
> some specifics thus we need to answer following questions:
> 
> - some devices handles almost all MAC in firmware; some - handle control frame 
> exchange in firmware, rest - on host; some use other separation of work 
> between host and firmware. So, quite flexible mechanism to specify offloading 
> of parts of .11 stack to firmware required. What is best way? 
> netdev->features?

Use function pointers for the handlers that can be overridden by the
driver, or something similar like that.

Start with "pure %100 software" stack, then once that is fully functional
work back to add the necessary hooks to support partial software stacks.

> - there are cases when PHY information needed, to make decisions (like select 
> AP from list), or for information purposes (sniffer). What is your vision how 
> to do this? I.e. provide some standard PHY header before MAC header, out of 
> band (use cb?)

This should be stored in the 802.11 specific information struct which
I allocate for each generic device which registers with the 802.11
layer.  There should be a standard 802.11 stack interface the driver
can use the pass the information in so that the details of the layout
inside of the 802.11 device information structure need not be exported
publicly.

> - there is PHY level information that may be needed for Tx:
> modulation;rate;retry policy and rates;Tx power;protection(RTS/CTS, CTS to 
> self). Same question as above: how to provide it?

Same way.

> - there is some interesting information that may come from Tx status, like 
> success indication, last rate, retry count, energy in channel after packet, 
> actual backoff time.

Feed it back into the software stack with some kind of function call.

> - is it feasible to do rate scaling in generic way in stack? Or should it be 
> done always in the driver?

I believe so.

> - Since WME and TGe introduction, NICs will likely to have multiple Tx queues. 
> It would be wise for driver to use multiple Tx queues and start/stop them 
> separately, like have all functions netif_start_queue() etc. have additional 
> parameter - queue number. Will it fit into your stack?

We can represent this using multiple generic netdev objects, perhaps.
Or we can finally start supporting multiple queues in the generic device
struct.  I like the latter idea better, and it allows us to do other things
as well.

Re: generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 1598 bytes --]

DS> > - there are cases when PHY information needed, to make decisions (like
 select DS> > AP from list), or for information purposes (sniffer). What is
 your vision how DS> > to do this? I.e. provide some standard PHY header
 before MAC header, out of DS> > band (use cb?)
DS>
DS> This should be stored in the 802.11 specific information struct which
DS> I allocate for each generic device which registers with the 802.11
DS> layer.  There should be a standard 802.11 stack interface the driver
DS> can use the pass the information in so that the details of the layout
DS> inside of the 802.11 device information structure need not be exported
DS> publicly.
DS>
DS> > - there is PHY level information that may be needed for Tx:
DS> > modulation;rate;retry policy and rates;Tx power;protection(RTS/CTS, CTS
 to DS> > self). Same question as above: how to provide it?
DS>
DS> Same way.

May be I did not stated the question clearly. This information need to be 
specified per packet. So question ramains: how to specify PHY info per skb.

DS>
DS> > - there is some interesting information that may come from Tx status,
 like DS> > success indication, last rate, retry count, energy in channel
 after packet, DS> > actual backoff time.
DS>
DS> Feed it back into the software stack with some kind of function call.
DS>
I tend to agree, with one note that it should be some mechanism to associate 
this information with original packet. One implementation example would be to 
keep original skb in some "in process" queue, and actually free it after Tx 
status arrival.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[David S. Miller]

On Tue, 7 Sep 2004 21:06:24 +0300
Vladimir Kondratiev <vkondra@mail.ru> wrote:

> May be I did not stated the question clearly. This information need to be 
> specified per packet. So question ramains: how to specify PHY info per skb.

Use the skb->cb[] area, create:

struct p80211_skb_cb {
	int rate;
	int channel;
	/* whatever... */
};

#define P80211_SKB_CB(skb)  ((struct p80211_skb_cb *)((skb)->cb))

Re: generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 1011 bytes --]

On Tuesday 07 September 2004 21:08, David S. Miller wrote:
DS> On Tue, 7 Sep 2004 21:06:24 +0300
DS> Vladimir Kondratiev <vkondra@mail.ru> wrote:
DS>
DS> > May be I did not stated the question clearly. This information need to
 be DS> > specified per packet. So question ramains: how to specify PHY info
 per skb. DS>
DS> Use the skb->cb[] area, create:
DS>
DS> struct p80211_skb_cb {
DS>  int rate;
DS>  int channel;
DS>  /* whatever... */
DS> };
DS>
DS> #define P80211_SKB_CB(skb)  ((struct p80211_skb_cb *)((skb)->cb))

This should be done in generic way. This information used to communicate 
berween particular driver and generic stack. For example, Rx PHY info and Tx 
status info should be used for in-stack generic rate scaling algorithm.

To complicate it a bit, cb[] is only 48 bytes long. PHY info may easily exceed 
this size, so it's better to allocate something and free it in destructor.

But again, point is this structure should be generic since it is used by 
stack.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[David S. Miller]

On Tue, 7 Sep 2004 21:41:54 +0300
Vladimir Kondratiev <vkondra@mail.ru> wrote:

> This should be done in generic way. This information used to communicate 
> berween particular driver and generic stack. For example, Rx PHY info and Tx 
> status info should be used for in-stack generic rate scaling algorithm.
> 
> To complicate it a bit, cb[] is only 48 bytes long. PHY info may easily exceed 
> this size, so it's better to allocate something and free it in destructor.
> 
> But again, point is this structure should be generic since it is used by 
> stack.

TCP does the same thing, and if space is an issue you can use
pointers in the cb[] area, other subsystems do this.

Re: generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

DS> > This should be done in generic way. This information used to
 communicate DS> > berween particular driver and generic stack. For example,
 Rx PHY info and Tx DS> > status info should be used for in-stack generic
 rate scaling algorithm. DS> >
DS> > To complicate it a bit, cb[] is only 48 bytes long. PHY info may easily
 exceed DS> > this size, so it's better to allocate something and free it in
 destructor. DS> >
DS> > But again, point is this structure should be generic since it is used
 by DS> > stack.
DS>
DS> TCP does the same thing, and if space is an issue you can use
DS> pointers in the cb[] area, other subsystems do this.

Sure, I agree. But this structure for PHY should be defined in stack, it is 
not driver's decision.

Actually, I'd like to fit this stack into real life.

To get real, I want, for some wireless card, write driver that will be able to 
Tx/Rx 802.11 frames, and let stack handle the rest. Like association, 
roaming... What should be done to get to this stage?

Jeff, your opinion on this?

Sam (you represent Atheros?), would you like to cooperate to make this 
possible?

Anyone doing drivers for Intersil and Broadcom, are you on this list? Would 
you join this effort?

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[Sam Leffler]

On Sep 7, 2004, at 12:54 PM, Vladimir Kondratiev wrote:

> Sam (you represent Atheros?), would you like to cooperate to make this
> possible?

I do not represent Atheros.  I'm happy to offer advise but have zero 
time to write code.

	Sam

Re: generic 802.11 stack

[Luis R. Rodriguez]

On Tue, Sep 07, 2004 at 10:54:12PM +0300, Vladimir Kondratiev wrote:
> Anyone doing drivers for Intersil and Broadcom, are you on this list? Would 
> you join this effort?

In regards to Intersil 802.11g chipsets and new card support lead by the 
prism54 project, we haven't yet been provided with specs for the new 
softmac chipsets nor an updated source base but regardless I'm sure
we'll have to do a lot of cleaning/code nuking so sure why not.

We still have work to complete for prism54 and have nothing solid to work on
for a new softmac driver so participation with this effort may take a
while. If we don't hear back from Conexant in regards to the softmac
chipsets we will just have to use that old code posted earlier as base
for new development.

The softmac driver is "supposed" to be backward compatible with the
fullmac chipsets as well as with the firmware for them but I've heard
this backward compatiblity has been broken. This is unfortunate as if
this backward compatibility does not work it would be the requirement of
two separate prism54-type drivers.

We've also discussed re-writing our current fullmac driver for two
purposes:

1. Dual licensing (FBSD/GPL)
2. Start using/help writing this new generic 802.11 stack
3. Cleaning the code

It may be the case that we can just re-write the fullmac driver in hopes
that we can later adapt/include softmac code. We need questions answered
for this though so hopefully Conexant will start talking to us again.

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[greg chesson]

Oh really?

What about eth_type_trans()?
It is not implemented as a true network stack.
Many drivers call it, but it is a gross input packet
hooked eater thing that's an ugly wart bolted onto the
side of the driver API.

what's good for the goose, etc.

My point is that there is ample precedent in the OS for common
  driver "assistance" subroutines that contain protocol knowledge or 
implement
policy yet are not implemented in strict stack-like manner
because it didn't make sense to do 'em that way.

It seems to me that Sam's net80211 code is performing three essential
functions:
1. encap/decap service for converting between 802.3 and 802.11
2. the MLME protocol (802.11 management messages and state keeping)
3. interface to upper layer ioctl stuff, particularly user-land crypto 
supplicants
     and authenticators in addition to the usual group of tools.

The MLME protocol works as a stack already since it really does 
implement a protocol.
The encap/decap could be implemented stack-like instead of 
eth_type_trans-like,
but it seems very suboptimal to do it another way.   The ioctl 
interfaces are a wart on the side
of the driver API anyway, but let's not have an argument about that 
since it is
a design feature of the OS inherited from unix.

The complaint seems to be mainly about the encap/decap procedures
which are implemented more as driver helper functions.
If somebody wants to rewrite them as a stack, then go for it.
I'll be interested in seeing whether or not good methods can be found
for exporting driver-local information (e.g. the mac address of the AP,
or the tx PHY rate needed to calculate the duration field value,
or whether or not to do mac tx fragmentation, etc)
up the stack without creating a pile of spaghetti to rival Microsoft's
failed "native 802.11" project.

I've thought about this problem and don't think there is a good answer
if a layered approach to protocol implementation stipulates that each layer
be self-contained.    The 802.11 situation requires more data-sharing
between layers than is conducive to a strict layering approach.
I suspect that what's needed is a data structure tailored to wireless
which can be shared between layers and common across devices.
Perhaps it could be an extention to dev (wdev?) that captures
the necessary sharing.    But the problems don't stop there.
Think for a moment about where power-save should be implemented -
which layer?

cheers,

g





Sam Leffler wrote:
> On Monday 06 September 2004 06:23 pm, David S. Miller wrote:
> 
>>On Mon, 6 Sep 2004 11:13:31 -0700
>>
>>Sam Leffler <sam@errno.com> wrote:
>>
>>>I've suggested this code as a good starting point for a "generic 802.11
>>>stack" but received only misinformed responses.
>>
>>Sam, I've told you multiple times why your stack isn't a good
>>starting point.  It isn't implemented as a true network stack,
>>like IPV4, Appletalk, etc.  Instead it's a gross input packet
>>hooked packet eater thing that's an ugly wart bolted onto the
>>side of the driver API.
> 
> 
> Actually, this is the first time you've said anything to me about this code.  
> We corresponded intensely for about a week 2+ years ago after which you 
> declared you now knew how to "write an 802.11 stack right" and were going to 
> do it that weekend.  I waited but it seems the sum total result was the shell 
> of code that Jeff referenced in a previous note.
> 
> Perhaps you can point me at a description of what a "true network stack" means 
> to you.  I'm guessing this has to do with your wanting queues inserted at 
> various places instead of direct handoffs.  Regardless, I've never suggested 
> the current code is suitable as-is but rather should be reshaped to suit the 
> intended structure of the system.  There is a lot of hard-earned experience 
> in the code that is independent of coding style and operational 
> infrastructure.
> 
> Anyway, the point of my note was to correct a comment in the original posting 
> and make folks aware that working code existed from which they could crib 
> stuff.  Good luck finding someone to reimplement eveything according to your 
> wishes.
> 
> 	Sam



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[David S. Miller]

On Tue, 07 Sep 2004 10:03:41 -0700
greg chesson <greg@atheros.com> wrote:

> What about eth_type_trans()?

It determines the protocol type from the ethernet header
fields.  It is a simple shorthand header field fetcher,
not a protocol stack.

You would need a eth80211_type_trans() for wireless
drivers too, and surprise surprise my skeleton 802.11
stack code in fact does exactly this.

> I've thought about this problem and don't think there is a good answer
> if a layered approach to protocol implementation stipulates that each layer
> be self-contained.

In my 802.11 stack the 802.11 information structure can be
found given a generic device pointer.  All the wireless info
can be retrieved from that, and you can use it to call the
wireless stack routines if you wish as well.

This is no different than how we keep ipv4 information hooked
onto the generic device structure and walk between these various
entities in the ipv4 and generic networking code.

Please read my skeletal stack code, it is exactly how I truly
believe something like this should be architected.  It's all
the base layout stuff that's important, the rest are details
that will fit in cleanly and readily once you have a solid
and firm foundation.

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[greg chesson]

I certainly agree with you about getting the base design right.
Where are these bits you refer to?

g

David S. Miller wrote:
> On Tue, 07 Sep 2004 10:03:41 -0700
> greg chesson <greg@atheros.com> wrote:
> 
> 
>>What about eth_type_trans()?
> 
> 
> It determines the protocol type from the ethernet header
> fields.  It is a simple shorthand header field fetcher,
> not a protocol stack.
> 
> You would need a eth80211_type_trans() for wireless
> drivers too, and surprise surprise my skeleton 802.11
> stack code in fact does exactly this.
> 
> 
>>I've thought about this problem and don't think there is a good answer
>>if a layered approach to protocol implementation stipulates that each layer
>>be self-contained.
> 
> 
> In my 802.11 stack the 802.11 information structure can be
> found given a generic device pointer.  All the wireless info
> can be retrieved from that, and you can use it to call the
> wireless stack routines if you wish as well.
> 
> This is no different than how we keep ipv4 information hooked
> onto the generic device structure and walk between these various
> entities in the ipv4 and generic networking code.
> 
> Please read my skeletal stack code, it is exactly how I truly
> believe something like this should be architected.  It's all
> the base layout stuff that's important, the rest are details
> that will fit in cleanly and readily once you have a solid
> and firm foundation.
> 

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[David S. Miller]

On Tue, 07 Sep 2004 11:14:17 -0700
greg chesson <greg@atheros.com> wrote:

> I certainly agree with you about getting the base design right.
> Where are these bits you refer to?

See earlier in this very thread you are replying to:

http://marc.theaimsgroup.com/?l=linux-netdev&m=109415745726088&w=2

:-)

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[jamal]

On Tue, 2004-09-07 at 13:10, David S. Miller wrote:
> On Tue, 07 Sep 2004 10:03:41 -0700
> greg chesson <greg@atheros.com> wrote:
> 
> > What about eth_type_trans()?
> 
> It determines the protocol type from the ethernet header
> fields.  It is a simple shorthand header field fetcher,
> not a protocol stack.
> 
> You would need a eth80211_type_trans() for wireless
> drivers too, and surprise surprise my skeleton 802.11
> stack code in fact does exactly this.

Or as Andi has been suggesting for sometime, not invoke it all ;->
This is possible if the DMA descriptor already has all the info
needed (quiet a few modern hardware can be programmed to do this).
.. er, at the driver level. So this is not "a gross input packet
hooked eater thing that's an ugly wart bolted onto the
side of the driver API.";->

cheers,
jamal

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[greg chesson]

You guys are too serious and, I believe, missed the real points.

1.  There is a need in the OS for a "service" to convert between
       .11 and .3 packet formats.   It should be designed for 
hw-independence.
      Everyone sees the same potential for unification
       of wireless drivers.

2.  It's harder to do than it first appears because the complete
      transformation from .3 to .11 cannot be done in isolation
      from the driver(s) and there are monkey wrenches that get
      tossed in from crypto, interaction between crypto and fragementation,
      power-save, observing txoplimits, and other things that tend
      to cross architecture lines that would otherwise be nice and clean.

3.  I personally don't have religion about whether a service
      that transforms headers is implemented as a stack or implemented
      as a side call.   I think that a variety of factors are worth 
considering.
      In this particular case (header transformation), I believe a side call
      "helper function" is appropriate and has less overhead than the full
      protocol stack mechanism.   But it's pointless to argue about it 
without
      measurements.

4.  David's skeleton code is quite interesting and a good start.
       You won't know its usefulness until someone tries to implement
      a real driver.

g



jamal wrote:
> On Tue, 2004-09-07 at 13:10, David S. Miller wrote:
> 
>>On Tue, 07 Sep 2004 10:03:41 -0700
>>greg chesson <greg@atheros.com> wrote:
>>
>>
>>>What about eth_type_trans()?
>>
>>It determines the protocol type from the ethernet header
>>fields.  It is a simple shorthand header field fetcher,
>>not a protocol stack.
>>
>>You would need a eth80211_type_trans() for wireless
>>drivers too, and surprise surprise my skeleton 802.11
>>stack code in fact does exactly this.
> 
> 
> Or as Andi has been suggesting for sometime, not invoke it all ;->
> This is possible if the DMA descriptor already has all the info
> needed (quiet a few modern hardware can be programmed to do this).
> .. er, at the driver level. So this is not "a gross input packet
> hooked eater thing that's an ugly wart bolted onto the
> side of the driver API.";->
> 
> cheers,
> jamal
> 
> 
> 



-------------------------------------------------------
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 3582 bytes --]

Greg,
you missed one important point. Besides data packets, that every driver now 
convert .11<->.3 using almost the same code, there is whole story of 
management. Many modern cards are "softmac" and do all management on host. I 
see no point for every driver to implement its own scanning and association. 
It is simply waste of resources.

To make step forward, I suggest the following:

1. Dave's code is at least year old. someone need to start maintain it, 
starting with update for current kernel infrastructure. Get it compile and 
load for 2.6.9, for example.

2. To debug stack, you don't need real driver. I can write dummy .11 driver 
that will silently discard all Tx, and will provide some way for user level 
tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it 
is sufficient. Later, when it will come to timing, performance etc, it will 
be easy to strip some real driver.

This may be king of "proof of concept".

Vladimir

On Wednesday 08 September 2004 19:02, greg chesson wrote:
gc> You guys are too serious and, I believe, missed the real points.
gc>
gc> 1.  There is a need in the OS for a "service" to convert between
gc>        .11 and .3 packet formats.   It should be designed for
gc> hw-independence.
gc>       Everyone sees the same potential for unification
gc>        of wireless drivers.
gc>
gc> 2.  It's harder to do than it first appears because the complete
gc>       transformation from .3 to .11 cannot be done in isolation
gc>       from the driver(s) and there are monkey wrenches that get
gc>       tossed in from crypto, interaction between crypto and
 fragementation, gc>       power-save, observing txoplimits, and other things
 that tend gc>       to cross architecture lines that would otherwise be nice
 and clean. gc>
gc> 3.  I personally don't have religion about whether a service
gc>       that transforms headers is implemented as a stack or implemented
gc>       as a side call.   I think that a variety of factors are worth
gc> considering.
gc>       In this particular case (header transformation), I believe a side
 call gc>       "helper function" is appropriate and has less overhead than
 the full gc>       protocol stack mechanism.   But it's pointless to argue
 about it gc> without
gc>       measurements.
gc>
gc> 4.  David's skeleton code is quite interesting and a good start.
gc>        You won't know its usefulness until someone tries to implement
gc>       a real driver.
gc>
gc> g
gc>
gc>
gc>
gc> jamal wrote:
gc> > On Tue, 2004-09-07 at 13:10, David S. Miller wrote:
gc> >
gc> >>On Tue, 07 Sep 2004 10:03:41 -0700
gc> >>greg chesson <greg@atheros.com> wrote:
gc> >>
gc> >>
gc> >>>What about eth_type_trans()?
gc> >>
gc> >>It determines the protocol type from the ethernet header
gc> >>fields.  It is a simple shorthand header field fetcher,
gc> >>not a protocol stack.
gc> >>
gc> >>You would need a eth80211_type_trans() for wireless
gc> >>drivers too, and surprise surprise my skeleton 802.11
gc> >>stack code in fact does exactly this.
gc> >
gc> >
gc> > Or as Andi has been suggesting for sometime, not invoke it all ;->
gc> > This is possible if the DMA descriptor already has all the info
gc> > needed (quiet a few modern hardware can be programmed to do this).
gc> > .. er, at the driver level. So this is not "a gross input packet
gc> > hooked eater thing that's an ugly wart bolted onto the
gc> > side of the driver API.";->
gc> >
gc> > cheers,
gc> > jamal
gc> >
gc> >
gc> >
gc>
gc>
gc>
gc>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[greg chesson]

Vladimir Kondratiev wrote:
> Greg,
> you missed one important point. Besides data packets, that every driver now 
> convert .11<->.3 using almost the same code, there is whole story of 
> management. Many modern cards are "softmac" and do all management on host. I 
> see no point for every driver to implement its own scanning and association. 

Yes, Quite right.  No disagreement.
It is standard practice on NDIS and Apple Darwin that a common GUI-based
application controls scanning, association, and manages 
keys+authentication+crypto.

Linux does the same thing (driver is configured by application code)
  although there does not yet exist a single app
that can serve as a common point of control for multiple vendor drivers.
I believe that achieving that goal is the real payoff for wireless Linux 
users.

> It is simply waste of resources.
> 
> To make step forward, I suggest the following:
> 
> 1. Dave's code is at least year old. someone need to start maintain it, 
> starting with update for current kernel infrastructure. Get it compile and 
> load for 2.6.9, for example.
> 
> 2. To debug stack, you don't need real driver. I can write dummy .11 driver 
> that will silently discard all Tx, and will provide some way for user level 
> tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it 
> is sufficient. Later, when it will come to timing, performance etc, it will 
> be easy to strip some real driver.
> 
> This may be king of "proof of concept".

Yes, for logic it is sufficient.
My personal approach would be to test the theory by examining
what fits or doesn't fit into David's API if I were to port one of the
MLME implementations that I work with.   Discover if it fits or not.


> 
> Vladimir
> 
> On Wednesday 08 September 2004 19:02, greg chesson wrote:
> gc> You guys are too serious and, I believe, missed the real points.
> gc>
> gc> 1.  There is a need in the OS for a "service" to convert between
> gc>        .11 and .3 packet formats.   It should be designed for
> gc> hw-independence.
> gc>       Everyone sees the same potential for unification
> gc>        of wireless drivers.
> gc>
> gc> 2.  It's harder to do than it first appears because the complete
> gc>       transformation from .3 to .11 cannot be done in isolation
> gc>       from the driver(s) and there are monkey wrenches that get
> gc>       tossed in from crypto, interaction between crypto and
>  fragementation, gc>       power-save, observing txoplimits, and other things
>  that tend gc>       to cross architecture lines that would otherwise be nice
>  and clean. gc>
> gc> 3.  I personally don't have religion about whether a service
> gc>       that transforms headers is implemented as a stack or implemented
> gc>       as a side call.   I think that a variety of factors are worth
> gc> considering.
> gc>       In this particular case (header transformation), I believe a side
>  call gc>       "helper function" is appropriate and has less overhead than
>  the full gc>       protocol stack mechanism.   But it's pointless to argue
>  about it gc> without
> gc>       measurements.
> gc>
> gc> 4.  David's skeleton code is quite interesting and a good start.
> gc>        You won't know its usefulness until someone tries to implement
> gc>       a real driver.
> gc>
> gc> g
> gc>
> gc>
> gc>
> gc> jamal wrote:
> gc> > On Tue, 2004-09-07 at 13:10, David S. Miller wrote:
> gc> >
> gc> >>On Tue, 07 Sep 2004 10:03:41 -0700
> gc> >>greg chesson <greg@atheros.com> wrote:
> gc> >>
> gc> >>
> gc> >>>What about eth_type_trans()?
> gc> >>
> gc> >>It determines the protocol type from the ethernet header
> gc> >>fields.  It is a simple shorthand header field fetcher,
> gc> >>not a protocol stack.
> gc> >>
> gc> >>You would need a eth80211_type_trans() for wireless
> gc> >>drivers too, and surprise surprise my skeleton 802.11
> gc> >>stack code in fact does exactly this.
> gc> >
> gc> >
> gc> > Or as Andi has been suggesting for sometime, not invoke it all ;->
> gc> > This is possible if the DMA descriptor already has all the info
> gc> > needed (quiet a few modern hardware can be programmed to do this).
> gc> > .. er, at the driver level. So this is not "a gross input packet
> gc> > hooked eater thing that's an ugly wart bolted onto the
> gc> > side of the driver API.";->
> gc> >
> gc> > cheers,
> gc> > jamal
> gc> >
> gc> >
> gc> >
> gc>
> gc>
> gc>
> gc
> 

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

gc>
gc> Linux does the same thing (driver is configured by application code)
gc>   although there does not yet exist a single app
gc> that can serve as a common point of control for multiple vendor drivers.
gc> I believe that achieving that goal is the real payoff for wireless Linux
gc> users.

I would not fully agree here: for timing reasons, you can do scanning/AP 
selection in user space, but for rate scaling, if we ever can do it generic, 
you better be in kernel.
From architecture point of view, MLME should be stack, not user app. For me, 
management packets generation is same kind of activity as arp. 

gc>
gc> > It is simply waste of resources.
gc> >
gc> > To make step forward, I suggest the following:
gc> >
gc> > 1. Dave's code is at least year old. someone need to start maintain it,
gc> > starting with update for current kernel infrastructure. Get it compile
 and gc> > load for 2.6.9, for example.
gc> >
gc> > 2. To debug stack, you don't need real driver. I can write dummy .11
 driver gc> > that will silently discard all Tx, and will provide some way
 for user level gc> > tool to simulate Rx (ioctl, netlink, does not really
 matter). For logic, it gc> > is sufficient. Later, when it will come to
 timing, performance etc, it will gc> > be easy to strip some real driver.
gc> >
gc> > This may be king of "proof of concept".
gc>
gc> Yes, for logic it is sufficient.
gc> My personal approach would be to test the theory by examining
gc> what fits or doesn't fit into David's API if I were to port one of the
gc> MLME implementations that I work with.   Discover if it fits or not.

Sounds promising. Don't forget to share you findings.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[greg chesson]

good discussion.  some complementary thoughts below.

Vladimir Kondratiev wrote:
> gc>
> gc> Linux does the same thing (driver is configured by application code)
> gc>   although there does not yet exist a single app
> gc> that can serve as a common point of control for multiple vendor drivers.
> gc> I believe that achieving that goal is the real payoff for wireless Linux
> gc> users.
> 
> I would not fully agree here: for timing reasons, you can do scanning/AP 
> selection in user space, but for rate scaling, if we ever can do it generic, 
> you better be in kernel.
Existing APIs have a command to tell the driver to scan and return the 
result.
There are sometimes parameters to limit the scan to a certain amount of time
or certain channels or to sort the scan results on some metric, e.g. is-WPA.
The user-space app then selects an AP and commands the driver to associate.
That's all fine and well-understood.

An exception to this arrangement is background scanning where the driver
is expected to go off-channel and search around for other APs while 
remaining
associated with one AP.   The driver goes into power-save state with the 
current
AP while doing the scan.  There's enough of a real-time component to this,
that it needs to be implemented in the driver.   An extreme example is 
the work
being done for voip over 802.11.   Every vendor as well as the 802.11 
TGe and TGr
groups are pursuing techniques whereby the wireless subsystem goes into
power-save between voip codec samples (usually at 20ms intervals) except 
for those
times when it is doing off-channel background scanning (also between 
codec samples!).
This is an interesting implementation challenge.... and it's also 
necessary since it is
the only way to get cell-phone equivalent battery life for 802.11 devices
while also running at 802.11 power and phy rates.    The phone people in 
TGr also
have a goal of implementing fast handoff of an active voip call between APs
within 20ms.   The heavy problem with that is moving the security context
in a low-overhead manner without opening up new security holes.
I can see the possibility of enabling fast handoff via application

> From architecture point of view, MLME should be stack, not user app. For me, 
> management packets generation is same kind of activity as arp. 
I agree with this and tried to say it in previous emails....
> 
<snip>

> gc> Yes, for logic it is sufficient.
> gc> My personal approach would be to test the theory by examining
> gc> what fits or doesn't fit into David's API if I were to port one of the
> gc> MLME implementations that I work with.   Discover if it fits or not.
> 
> Sounds promising. Don't forget to share you findings.

roger.

Re: generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

To inform about status:
I started to work on idea of 802.11 generic stack. I start from code by Dave. 
This far I fixed it to compile for 2.6 (Makefile and couple of syntax 
errors).
I am going to implement minimum functionality, at this stage I will somehow 
publish the project. Anyone can suggest what it the right solution for 
hosting? Sourceforge? Something else?
Vladimir

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[Jeff Garzik]

Vladimir Kondratiev wrote:
> To inform about status:
> I started to work on idea of 802.11 generic stack. I start from code by Dave. 
> This far I fixed it to compile for 2.6 (Makefile and couple of syntax 
> errors).
> I am going to implement minimum functionality, at this stage I will somehow 
> publish the project. Anyone can suggest what it the right solution for 
> hosting? Sourceforge? Something else?


I can put it into the wireless-2.6 queue, which is where I would prefer 
that work on a generic 802.11 stack went.

	Jeff




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: generic 802.11 stack

[David S. Miller]

On Sun, 12 Sep 2004 20:09:08 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:

> Vladimir Kondratiev wrote:
> > To inform about status:
> > I started to work on idea of 802.11 generic stack. I start from code by Dave. 
> > This far I fixed it to compile for 2.6 (Makefile and couple of syntax 
> > errors).
> > I am going to implement minimum functionality, at this stage I will somehow 
> > publish the project. Anyone can suggest what it the right solution for 
> > hosting? Sourceforge? Something else?
> 
> I can put it into the wireless-2.6 queue, which is where I would prefer 
> that work on a generic 802.11 stack went.

This is fine with me as well.


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: generic 802.11 stack

[James Ketrenos]

David S. Miller wrote:

>On Sun, 12 Sep 2004 20:09:08 -0400
>Jeff Garzik <jgarzik@pobox.com> wrote:
>  
>
>>Vladimir Kondratiev wrote:
>>    
>>
>>>To inform about status:
>>>I started to work on idea of 802.11 generic stack. I start from code by Dave. 
>>>This far I fixed it to compile for 2.6 (Makefile and couple of syntax 
>>>errors).
>>>I am going to implement minimum functionality, at this stage I will somehow 
>>>publish the project. Anyone can suggest what it the right solution for 
>>>hosting? Sourceforge? Something else?
>>>      
>>>
>>I can put it into the wireless-2.6 queue, which is where I would prefer 
>>that work on a generic 802.11 stack went.
>>    
>>
>
>This is fine with me as well.
>  
>
I have seen two paths that need to occur:

1) Creation of a generic 802.11 frame handling stack (management, data, 
etc.) sufficient to do .3 to .11 conversion, .11 fragmentation, state 
machine, etc.
2) Tight integration of a .11 stack into the kernel

The first step can occur with minimal changes to the rest of the 
kernel,  isolated completely within drivers/net/wireless.  Once a stack 
is there, all the drivers there can be adapted to use that.  This would 
seem reasonable to pull into the 2.6 stable series.

The second step will likely require more invasive changes to other parts 
of the networking stack and I hadn't thought such changes would be 
considered for 2.6.

Am I incorrect in the above?

We have been cleaning up the ipw2200/ipw2100 and their corresponding 
ieee80211 stack so that it could then be used with the other wifi 
drivers (adapting it to add back in features from HostAP that are 
currently stub'd out) in a non-intrusive way (we would like to get ipw* 
merged in soon).  We have a bk tree for this cloned from wireless-2.6 
avialable at ipw.bkbits.net/ipw-2.6.

Right now a driver can register with netdev's xmit to receive the 
ethernet frame and then pass it to ieee80211_skb_to_txb() to transform 
it into a chain of 802.11 fragments (encrypted if configured to do so) 
which the device can then pass to the HW.  I don't like the way the 
skb_to_txb transform occurs, but its working right now.  The next level 
of integration would be to have the device driver register an ieee80211 
stack callback as the xmit handler, and then register a .11 xmit with 
the ieee80211 stack.

Anyway, based on what I had read previously on this group, the sequence 
of steps I understood needing to be followed were:

0) Get the ipw2100 and ipw2200 drivers functionally complete so that end 
users can fully utilize that hardware.
1) Create generic ieee80211 frame handling stack.  HW specific piece 
should be limited to Tx/Rx of raw frames as much as possible (while 
supporting drivers that can not do full 802.11 frame tx/rx).  For 
nonintrusive inclusion in kernel, this would be achieved through calls 
into the ieee80211 stack from the driver vs. addition of netdev entry 
points.  To date this has been achieved by adding infrastructure into 
either the ipw2100 or ipw2200 project, then merging it into ieee80211 so 
that the other project could leverage it.
2) Adapt other drivers besides ipw2100 and ipw2200 to use the stack
3) Once 1 and 2 are stabilized, begin restructuring the entry points to 
more tightly integrate the .11 handling into the netdev core.

One area where I wasn't sure on how invasive it would be for stack 
optimizations deal with 802.11 fragmentation and encryption of said 
fragments such that TCP retries do not require 
re-fragmentation/encryption when host based enc/frag is enabled.

The next potentially invasive area is the addition of TGe support which 
Vladimir has discussed previously.

We based the current ieee80211 stack in part on the Host AP stack.  In 
looking through the madwifi stack, there are traights that it carries 
that would be nice to be able to use as well moving forward -- whether 
through code (CVS madwifi is licensed under a GPL compatible BSD 
license) or aspects of design. 

The whole of the ieee80211 stack (and ipw2100/ipw2200 drivers) are 
licensed under GPL version 2.

James

Re: generic 802.11 stack

[David S. Miller]

On Sun, 12 Sep 2004 21:03:13 +0300
Vladimir Kondratiev <vkondra@mail.ru> wrote:

> I am going to implement minimum functionality, at this stage I will somehow 
> publish the project. Anyone can suggest what it the right solution for 
> hosting? Sourceforge? Something else?

I am willing to host things for you, if you wish.
I can make a directory in my personal area on ftp.kernel.org
and that's where I'd put your patches.

I'd also like to help review your patches, so I can perform
both things at the same time.


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 791 bytes --]

Dave,
Thanks, I'll post patches to you.

Jeff: what would you say? I think it is great if it will went through Dave 
with his review.

Vladimir.

On Monday 13 September 2004 03:14, David S. Miller wrote:
DS> On Sun, 12 Sep 2004 21:03:13 +0300
DS> Vladimir Kondratiev <vkondra@mail.ru> wrote:
DS>
DS> > I am going to implement minimum functionality, at this stage I will
 somehow DS> > publish the project. Anyone can suggest what it the right
 solution for DS> > hosting? Sourceforge? Something else?
DS>
DS> I am willing to host things for you, if you wish.
DS> I can make a directory in my personal area on ftp.kernel.org
DS> and that's where I'd put your patches.
DS>
DS> I'd also like to help review your patches, so I can perform
DS> both things at the same time.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[Jeff Garzik]

Vladimir Kondratiev wrote:
> Dave,
> Thanks, I'll post patches to you.
> 
> Jeff: what would you say? I think it is great if it will went through Dave 
> with his review.


You are the one doing the work.  Which would you prefer?  :)

You could always send patches to netdev@oss.sgi.com and CC 
jgarzik@pobox.com and davem@davemloft.net.  DaveM could review, and I 
could apply to wireless-2.6, then post a snapshot on kernel.org.

	Jeff




-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: generic 802.11 stack

[David S. Miller]

On Mon, 13 Sep 2004 01:50:39 -0400
Jeff Garzik <jgarzik@pobox.com> wrote:

> You are the one doing the work.  Which would you prefer?  :)
> 
> You could always send patches to netdev@oss.sgi.com and CC 
> jgarzik@pobox.com and davem@davemloft.net.  DaveM could review, and I 
> could apply to wireless-2.6, then post a snapshot on kernel.org.

That works for me.


-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On Tuesday 14 September 2004 02:21, David S. Miller wrote:
DS> On Mon, 13 Sep 2004 01:50:39 -0400
DS> Jeff Garzik <jgarzik@pobox.com> wrote:
DS>
DS> > You are the one doing the work.  Which would you prefer?  :)
DS> >
DS> > You could always send patches to netdev@oss.sgi.com and CC
DS> > jgarzik@pobox.com and davem@davemloft.net.  DaveM could review, and I
DS> > could apply to wireless-2.6, then post a snapshot on kernel.org.
DS>
DS> That works for me.

Fine. Let it be this way. It may take for me some time till I can sumbit 
something, I want that it will kind of work with minimum functionality.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[David S. Miller]

On Tue, 14 Sep 2004 08:14:56 +0300
Vladimir Kondratiev <vkondra@mail.ru> wrote:

> Fine. Let it be this way. It may take for me some time till I can sumbit 
> something, I want that it will kind of work with minimum functionality.

Ok, good luck Vladimir :-)



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php

Re: generic 802.11 stack

[Luis R. Rodriguez]

On Mon, Sep 13, 2004 at 10:35:00PM -0700, David S. Miller wrote:
> On Tue, 14 Sep 2004 08:14:56 +0300
> Vladimir Kondratiev <vkondra@mail.ru> wrote:
> 
> > Fine. Let it be this way. It may take for me some time till I can sumbit 
> > something, I want that it will kind of work with minimum functionality.
> 
> Ok, good luck Vladimir :-)

Vladimir,

How about dual-licensing this work as GPL/BSD? I believe the BSD teams might
benefit from this work.

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

Re: generic 802.11 stack

[Jeff Garzik]

Luis R. Rodriguez wrote:
> On Mon, Sep 13, 2004 at 10:35:00PM -0700, David S. Miller wrote:
> 
>>On Tue, 14 Sep 2004 08:14:56 +0300
>>Vladimir Kondratiev <vkondra@mail.ru> wrote:
>>
>>
>>>Fine. Let it be this way. It may take for me some time till I can sumbit 
>>>something, I want that it will kind of work with minimum functionality.
>>
>>Ok, good luck Vladimir :-)
> 
> 
> Vladimir,
> 
> How about dual-licensing this work as GPL/BSD? I believe the BSD teams might
> benefit from this work.


While I don't mind dual-licensing per se, I really dislike the 
associated _technical_ crap that comes along with it, namely

* cross-OS compatibility wrappers
* attempts to pretend that locking is _remotely_ similar between BSD and 
Linux net stacks
* use of non-Linux coding styles and memes
* over-engineering and over-abstraction


Linus Credo #788 is "do what you must, and no more."

If Vladimir is working from DaveM's code template, then he is working at 
the lowest, most native _Linux kernel_ levels to interface with the net 
stack.

I'm all for code sharing -- but I'm all for rationality too.  There will 
_inevitably_ be _fundamental_ differences between BSD and Linux net 
stacks, and to attempt to code for both OS's will be nasty and time 
consuming, IMHO.

	Jeff

Re: generic 802.11 stack

[greg chesson]

Jeff Garzik wrote:
<snip>
> 
> 
> While I don't mind dual-licensing per se, I really dislike the 
> associated _technical_ crap that comes along with it, namely
> 
> * cross-OS compatibility wrappers
> * attempts to pretend that locking is _remotely_ similar between BSD and 
> Linux net stacks
> * use of non-Linux coding styles and memes
> * over-engineering and over-abstraction
> 

<snip>

I won't try to argue that these are not valid points -
except for maybe the last one because it is so subjective.
But not in this email.

I do argue that these points are not relevant to the question
of  whether or not a strict stack model of 802.11 management
and encapsulation procedures will suffice for anything more
than the most basic functionality.   That is an interesting question
that deserves an answer.

Personally, I think it will be necessary to have more shared information 
and procedures between
driver and 802.11 stack than is convenient or elegant in a strict stack 
arrangement.
  But, I've been wrong before.
Perhaps a fresh start with unbiased implementation will do something 
wonderful.
I look forward to seeing how a new implementation deals with the 
power-save packets
in the presence of qos, crypto, and fragmentation - all of which are 
necessary evils
if you want to pass wifi certification tests.

g

Re: generic 802.11 stack

[Jeff Garzik]

greg chesson wrote:
> I won't try to argue that these are not valid points -
> except for maybe the last one because it is so subjective.
> But not in this email.
> 
> I do argue that these points are not relevant to the question
> of  whether or not a strict stack model of 802.11 management
> and encapsulation procedures will suffice for anything more
> than the most basic functionality.   That is an interesting question
> that deserves an answer.

Agreed.


> Personally, I think it will be necessary to have more shared information 
> and procedures between
> driver and 802.11 stack than is convenient or elegant in a strict stack 
> arrangement.
>  But, I've been wrong before.
> Perhaps a fresh start with unbiased implementation will do something 
> wonderful.

That's precisely what I want -- an elegant strict stack arrangement :)

Since DaveM's template is _the_ net stack, I'm worried that BSD 
compatibility will only slow development and encumber innovation. 
Surely they can watch what we're doing, learn from our mistakes, and do 
something even better :)

	Jeff

Re: generic 802.11 stack

[Luis R. Rodriguez]

On Tue, Sep 14, 2004 at 09:19:24PM -0400, Jeff Garzik wrote:
> greg chesson wrote:
> >I won't try to argue that these are not valid points -
> >except for maybe the last one because it is so subjective.
> >But not in this email.
> >
> >I do argue that these points are not relevant to the question
> >of  whether or not a strict stack model of 802.11 management
> >and encapsulation procedures will suffice for anything more
> >than the most basic functionality.   That is an interesting question
> >that deserves an answer.
> 
> Agreed.
> 
> 
> >Personally, I think it will be necessary to have more shared information 
> >and procedures between
> >driver and 802.11 stack than is convenient or elegant in a strict stack 
> >arrangement.
> > But, I've been wrong before.
> >Perhaps a fresh start with unbiased implementation will do something 
> >wonderful.
> 
> That's precisely what I want -- an elegant strict stack arrangement :)
> 
> Since DaveM's template is _the_ net stack, I'm worried that BSD 
> compatibility will only slow development and encumber innovation. 
> Surely they can watch what we're doing, learn from our mistakes, and do 
> something even better :)

I proposed dual licensing not to specifically allow clear compatibility
among linux and the BSDs on the 802.11 work, but to allow BSDers to do
whatever they want with what we come up with -- help with code sharing.

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

Re: generic 802.11 stack

[Jeff Garzik]

On Tue, Sep 14, 2004 at 11:02:11PM -0400, Luis R. Rodriguez wrote:
> I proposed dual licensing not to specifically allow clear compatibility
> among linux and the BSDs on the 802.11 work, but to allow BSDers to do
> whatever they want with what we come up with -- help with code sharing.


Overall, He Who Writes The Code Gets To Choose.

My own personal opinion is that the BSD license goes against the stated
spirit of Linux -- contribute back.  But that's just me.

	Jeff

Re: generic 802.11 stack

[Luis R. Rodriguez]

On Tue, Sep 14, 2004 at 11:05:45PM -0400, Jeff Garzik wrote:
> On Tue, Sep 14, 2004 at 11:02:11PM -0400, Luis R. Rodriguez wrote:
> > I proposed dual licensing not to specifically allow clear compatibility
> > among linux and the BSDs on the 802.11 work, but to allow BSDers to do
> > whatever they want with what we come up with -- help with code sharing.
> 
> 
> Overall, He Who Writes The Code Gets To Choose.
> 
> My own personal opinion is that the BSD license goes against the stated
> spirit of Linux -- contribute back.  But that's just me.
> 

Agreed -- but in this case I feel we're the bigger crowd so I wanted to
address to the *author* that I feel we should be considerate to the BSD
crowd.

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

Re: generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

Let me answer to the set of questions raised:

- dual licensing: I am not ready to answer for legal. I will discuss with 
proper people and answer.

- code style: regardless of answer on question above, I intend to do Linux 
work and will not care about compatibility macros. I really dislike such 
macros, they do make code hard to understand.

- information sharing (driver-stack): good question indeed. I am currently 
evaluating it. This far, I think I will supply some standard link layer 
information per packet. Like rate, RSSI etc. For Tx, it will include also 
crypto key for hardware assisted encryption, type of protection (RTS/CTS 
etc.) I believe it should be sufficient. To prove it, I am going to write 
some dummy .11 driver that will be capable to simulate any Rx, with user 
interface for feeding packets. I will use this driver to debug stack.

It is complex issue to support all combination of job separation between host 
and NIC, I will choose some model like "NIC do almost nothing" and will 
develop around it. 

Vladimir.

On Wednesday 15 September 2004 06:17, Luis R. Rodriguez wrote:
LR> On Tue, Sep 14, 2004 at 11:05:45PM -0400, Jeff Garzik wrote:
LR> > On Tue, Sep 14, 2004 at 11:02:11PM -0400, Luis R. Rodriguez wrote:
LR> > > I proposed dual licensing not to specifically allow clear
 compatibility LR> > > among linux and the BSDs on the 802.11 work, but to
 allow BSDers to do LR> > > whatever they want with what we come up with --
 help with code sharing. LR> >
LR> >
LR> > Overall, He Who Writes The Code Gets To Choose.
LR> >
LR> > My own personal opinion is that the BSD license goes against the stated
LR> > spirit of Linux -- contribute back.  But that's just me.
LR> >
LR>
LR> Agreed -- but in this case I feel we're the bigger crowd so I wanted to
LR> address to the *author* that I feel we should be considerate to the BSD
LR> crowd.
LR>
LR>  Luis
LR>

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[greg chesson]

Vladimir Kondratiev wrote:
> Let me answer to the set of questions raised:
> 
> - dual licensing: I am not ready to answer for legal. I will discuss with 
> proper people and answer.
end the end it is your choice.
> 
> - code style: regardless of answer on question above, I intend to do Linux 
> work and will not care about compatibility macros. I really dislike such 
> macros, they do make code hard to understand.
This is true - and it's not just compatibility macro's that force
the reader to find and read the macro before understanding the code.
But there is a fine line between macro's that are accepted as standard
practice in a kernel, e.g. LIST_INSERT_HEAD, and the same kind
of thing that is used in a driver for compatibility across different
versions of the Linux kernel or, dog save us, some other unix-like OS.
> 
> - information sharing (driver-stack): good question indeed. I am currently 
> evaluating it. This far, I think I will supply some standard link layer 
> information per packet. Like rate, RSSI etc. For Tx, it will include also 
> crypto key for hardware assisted encryption, type of protection (RTS/CTS 
> etc.) I believe it should be sufficient. To prove it, I am going to write 
> some dummy .11 driver that will be capable to simulate any Rx, with user 
> interface for feeding packets. I will use this driver to debug stack.
2 cents of advice: the rx path is the easier side.
the more complex and fun stuff happens on the tx side.
> 
> It is complex issue to support all combination of job separation between host 
> and NIC, I will choose some model like "NIC do almost nothing" and will 
> develop around it. 
very reasonable.
> 
> Vladimir.
> 
> On Wednesday 15 September 2004 06:17, Luis R. Rodriguez wrote:
> LR> On Tue, Sep 14, 2004 at 11:05:45PM -0400, Jeff Garzik wrote:
> LR> > On Tue, Sep 14, 2004 at 11:02:11PM -0400, Luis R. Rodriguez wrote:
> LR> > > I proposed dual licensing not to specifically allow clear
>  compatibility LR> > > among linux and the BSDs on the 802.11 work, but to
>  allow BSDers to do LR> > > whatever they want with what we come up with --
>  help with code sharing. LR> >
> LR> >
> LR> > Overall, He Who Writes The Code Gets To Choose.
> LR> >
> LR> > My own personal opinion is that the BSD license goes against the stated
> LR> > spirit of Linux -- contribute back.  But that's just me.
> LR> >
> LR>
> LR> Agreed -- but in this case I feel we're the bigger crowd so I wanted to
> LR> address to the *author* that I feel we should be considerate to the BSD
> LR> crowd.
> LR>
> LR>  Luis
> LR
> 



-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m

Re: generic 802.11 stack

[David S. Miller]

On Wed, 15 Sep 2004 07:47:36 -0700
greg chesson <greg@atheros.com> wrote:

> Vladimir Kondratiev wrote:
> > Let me answer to the set of questions raised:
> > 
> > - dual licensing: I am not ready to answer for legal. I will discuss with 
> > proper people and answer.
> end the end it is your choice.

He has to also ask the person who wrote the code he is
basing his work upon, and that would be me :-)

Re: generic 802.11 stack

[Sam Leffler]

On Wednesday 15 September 2004 08:55 am, David S. Miller wrote:
> On Wed, 15 Sep 2004 07:47:36 -0700
>
> greg chesson <greg@atheros.com> wrote:
> > Vladimir Kondratiev wrote:
> > > Let me answer to the set of questions raised:
> > >
> > > - dual licensing: I am not ready to answer for legal. I will discuss
> > > with proper people and answer.
> >
> > end the end it is your choice.
>
> He has to also ask the person who wrote the code he is
> basing his work upon, and that would be me :-)

That assumes he uses no code from somewhere else.  Given that your code didn't 
include any protocol implementation I suspect he'll be borrowing work from 
elsewhere....

	Sam

Re: generic 802.11 stack

[David S. Miller]

On Wed, 15 Sep 2004 09:48:57 -0700
Sam Leffler <sam@errno.com> wrote:

> On Wednesday 15 September 2004 08:55 am, David S. Miller wrote:
> > On Wed, 15 Sep 2004 07:47:36 -0700
> >
> > greg chesson <greg@atheros.com> wrote:
> > > Vladimir Kondratiev wrote:
> > > > Let me answer to the set of questions raised:
> > > >
> > > > - dual licensing: I am not ready to answer for legal. I will discuss
> > > > with proper people and answer.
> > >
> > > end the end it is your choice.
> >
> > He has to also ask the person who wrote the code he is
> > basing his work upon, and that would be me :-)
> 
> That assumes he uses no code from somewhere else.

Not at all.  If he wants to change the licensing of any
piece of code, he has to get permission from all the authors.

So, firstly, if he wants to take my code and extend it in any
way he'll need permission from me to use it as anything other
than pure GPL.

Secondly, if he wants to add BSD code to it he cannot do so
without working out the previous paragraph.


-------------------------------------------------------
This SF.Net email is sponsored by: thawte's Crypto Challenge Vl
Crack the code and win a Sony DCRHC40 MiniDV Digital Handycam
Camcorder. More prizes in the weekly Lunch Hour Challenge.
Sign up NOW http://ad.doubleclick.net/clk;10740251;10262165;m

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Luis R. Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 1176 bytes --]

On Wed, Sep 08, 2004 at 01:52:00PM -0700, greg chesson wrote:
> 
> 
> Vladimir Kondratiev wrote:
> >Greg,
> >you missed one important point. Besides data packets, that every driver 
> >now convert .11<->.3 using almost the same code, there is whole story of 
> >management. Many modern cards are "softmac" and do all management on host. 
> >I see no point for every driver to implement its own scanning and 
> >association. 
> 
> Yes, Quite right.  No disagreement.
> It is standard practice on NDIS and Apple Darwin that a common GUI-based
> application controls scanning, association, and manages 
> keys+authentication+crypto.
> 
> Linux does the same thing (driver is configured by application code)
>  although there does not yet exist a single app
> that can serve as a common point of control for multiple vendor drivers.
> I believe that achieving that goal is the real payoff for wireless Linux 
> users.
> 

<-- snip -->

RFC: what are the chances we can implement our own generic "softmac" that may
be usable by the different chipsets out there?

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Prism54-devel mailing list
Prism54-devel@prism54.org
http://prism54.org/mailman/listinfo/prism54-devel

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote:
LR> RFC: what are the chances we can implement our own generic "softmac" that
 may LR> be usable by the different chipsets out there?

Coming days, I will submit "framework" consisting of stack based on Dave's 
code and debug driver which will be able to imitate Rx. I have working basic 
Tx/Rx. Then, I'd like to concentrate on interfaces stack-driver and 
stack-upper layers. It would be great if someone will do MAC algorithms. I'll 
appreciate this for sure.

Vladimir.

P.S. My ... provider complains about "too many recipients". I removed one or 
2. Sorry.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Luis R. Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 876 bytes --]

On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote:
> On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote:
> LR> RFC: what are the chances we can implement our own generic "softmac" that may
> LR> be usable by the different chipsets out there?
> 
> Coming days, I will submit "framework" consisting of stack based on Dave's 
> code and debug driver which will be able to imitate Rx. I have working basic 
> Tx/Rx. Then, I'd like to concentrate on interfaces stack-driver and 
> stack-upper layers. It would be great if someone will do MAC algorithms. I'll 
> appreciate this for sure.

But would it be possible? Would it work, if we write our own softmac
interface? Or are softmac interaces/libraries strictly dependent on a
chipset being used?

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Prism54-devel mailing list
Prism54-devel@prism54.org
http://prism54.org/mailman/listinfo/prism54-devel

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]

On Wednesday 29 September 2004 02:48, Luis R. Rodriguez wrote:
LR> On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote:
LR> > On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote:
LR> > LR> RFC: what are the chances we can implement our own generic
 "softmac" that may LR> > LR> be usable by the different chipsets out there?
LR> >
LR> > Coming days, I will submit "framework" consisting of stack based on
 Dave's LR> > code and debug driver which will be able to imitate Rx. I have
 working basic LR> > Tx/Rx. Then, I'd like to concentrate on interfaces
 stack-driver and LR> > stack-upper layers. It would be great if someone will
 do MAC algorithms. I'll LR> > appreciate this for sure.
LR>
LR> But would it be possible? Would it work, if we write our own softmac
LR> interface? Or are softmac interaces/libraries strictly dependent on a
LR> chipset being used?
LR>
LR>  Luis
LR>
In idea yes, 802.11 stack should serve any low level driver provided it can 
Tx/Rx 802.11 frames. Just like Ethernet, where driver is very simple. The 
difference is, 802.11 stack is not written yet, we need to make sure we do it 
in smart way and with reasonable assumptions about what low level driver can 
do.

Thus far, I assume, low level driver (and NIC, of course) can:
-Tx/Rx arbitrary data and management packets. Control frames generated by NIC.
-NIC can perform scanning and report beacons or probe resp. to the stack.
-NIC can report some basic PHY data per packet: rate, RSSI, maybe something 
else.
-NIC accept some basic PHY data per packet on Tx: rate, retry count, 
protection, maybe Tx power and some others
-NIC can do crypto transformations on both Tx and Rx. For this, crypto key 
need be provided per packet for Tx and some ,mechanism to provide key for 
each peer need to be established for Rx.
-NIC may choose to not do fragmentation/reassembly, stack will handle it.
-NIC may have many Tx queues for QoS, it will be able to start/stop each one.

To not raise unsupported expectations: 802.11 stack is only skeleton for now. 
I will do interface parts first. For actual algorithms to handle managements 
flows, help required. But, I believe it is wise to write these algorithms 
once for this stack rather to implement whole stack with each driver.

Vladimir.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Luis R. Rodriguez]

[-- Attachment #1.1: Type: text/plain, Size: 2872 bytes --]

On Wed, Sep 29, 2004 at 09:10:08AM +0200, Vladimir Kondratiev wrote:
> On Wednesday 29 September 2004 02:48, Luis R. Rodriguez wrote:
> LR> On Tue, Sep 28, 2004 at 10:29:48PM +0200, Vladimir Kondratiev wrote:
> LR> > On Tuesday 28 September 2004 14:20, Luis R. Rodriguez wrote:
> LR> > LR> RFC: what are the chances we can implement our own generic
>  "softmac" that may LR> > LR> be usable by the different chipsets out there?
> LR> >
> LR> > Coming days, I will submit "framework" consisting of stack based on
>  Dave's LR> > code and debug driver which will be able to imitate Rx. I have
>  working basic LR> > Tx/Rx. Then, I'd like to concentrate on interfaces
>  stack-driver and LR> > stack-upper layers. It would be great if someone will
>  do MAC algorithms. I'll LR> > appreciate this for sure.
> LR>
> LR> But would it be possible? Would it work, if we write our own softmac
> LR> interface? Or are softmac interaces/libraries strictly dependent on a
> LR> chipset being used?
> LR>
> LR>  Luis
> LR>
> In idea yes, 802.11 stack should serve any low level driver provided it can 
> Tx/Rx 802.11 frames. Just like Ethernet, where driver is very simple. The 
> difference is, 802.11 stack is not written yet, we need to make sure we do it 
> in smart way and with reasonable assumptions about what low level driver can 
> do.
> 
> Thus far, I assume, low level driver (and NIC, of course) can:
> -Tx/Rx arbitrary data and management packets. Control frames generated by NIC.
> -NIC can perform scanning and report beacons or probe resp. to the stack.
> -NIC can report some basic PHY data per packet: rate, RSSI, maybe something 
> else.
> -NIC accept some basic PHY data per packet on Tx: rate, retry count, 
> protection, maybe Tx power and some others
> -NIC can do crypto transformations on both Tx and Rx. For this, crypto key 
> need be provided per packet for Tx and some ,mechanism to provide key for 
> each peer need to be established for Rx.
> -NIC may choose to not do fragmentation/reassembly, stack will handle it.
> -NIC may have many Tx queues for QoS, it will be able to start/stop each one.
> 
> To not raise unsupported expectations: 802.11 stack is only skeleton for now. 
> I will do interface parts first. For actual algorithms to handle managements 
> flows, help required. But, I believe it is wise to write these algorithms 
> once for this stack rather to implement whole stack with each driver.

OK great, then I'll try working Conexant to push for this as our goal
for a softmac driver for linux. Currently they use their own libraries
(not even a separate module, as atheros with its HAL). This is
unacceptable for kernel inclusion and that simply just sucks. Hopefully
this will be possible :)

	Luis

-- 
GnuPG Key fingerprint = 113F B290 C6D2 0251 4D84  A34A 6ADD 4937 E20A 525E

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 151 bytes --]

_______________________________________________
Prism54-devel mailing list
Prism54-devel@prism54.org
http://prism54.org/mailman/listinfo/prism54-devel

generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1.1: Type: text/plain, Size: 998 bytes --]

Attached is 1-st iteration for generic 802.11 stack framework.

Based on code from Dave.

I make it compile for 2.6 and wrote simple skeleton for native 802.11 driver. 

This skeleton is able to simulate Rx using ioctl; perl script to invoke ioctl 
included. Argument for script is binary frame image.

I removed all code for 802.11 header removal from p80211_type_trans for 
several reasons:
- I'd like to have all frames coming to stack with the same 802.11 header, 
this will help for sniffer
- header removal for data is a bit more complex: we should determine QoS 
header and strip 24 or 26 bytes.
- I'd like to do fragmentation and reassembly on stack, not in driver.

Nothing functional yet, but one can start debugging stack using Rx imitation; 
and driver do print packets it gets to Tx.


P.S. question:
I saw in all xxx_type_trans functions, skb->dev never assigned, it is done by 
driver instead. What is the reason? Why not assign skb->dev in 
xxx_type_trans?

[-- Attachment #1.2: p80211.tar.bz2 --]
[-- Type: application/x-tbz, Size: 10418 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[David S. Miller]

Why this change?

-extern void hh_data_is_too_small(void);
+static void hh_data_is_too_small(void)
+{
+    printk(KERN_ERR "hh_data_is_too_small\n");
+}

We don't define the function because it is meant to
cause a compile time error if hh->hh_data is too small to
hold the full p80211_data_header structure.  Please undo
this change.

And therefore undo this change too:

-	if (sizeof(hh->hh_data) < sizeof(*p))
+	if (sizeof(hh->hh_data) < sizeof(*p)) {
 		hh_data_is_too_small();
+        return -1;
+    }

Next, what's this?

-	dev->hard_header	= p80211_header;
+	dev->hard_header    	= p80211_header;
 	dev->rebuild_header 	= p80211_rebuild_header;

Your merely changing the tab character after dev->hard_header
into spaces.  Please don't do this.  This makes a lot of white
space noise when making diffs against the original davem-p80211
code thus making it harder to review the changes you actually made.

Next:

+    dev->mtu                = 2304;
+    dev->type               = ARPHRD_IEEE80211;

Is this really the correct default MTU for wireless devices?

@@ -342,7 +343,7 @@ int p80211_recv_cfackpoll(struct sk_buff
 static struct packet_type p80211_packet_type = {
 	.type	=	__constant_htons(ETH_P_802_11),
 	.func	=	p80211_rcv,
-	.data	=	(void *) 1, /* understands shared SKBs */
+	.af_packet_priv	=	(void *) 1, /* understands shared SKBs */
 };
 
You can just remove this line entirely for 2.6.x kernels.

Otherwise looks fine :-)

Re: generic 802.11 stack

[Vladimir Kondratiev]

[-- Attachment #1: Type: text/plain, Size: 2728 bytes --]

On Saturday 02 October 2004 00:53, David S. Miller wrote:
DS>
DS> Why this change?
DS>
DS> -extern void hh_data_is_too_small(void);
DS> +static void hh_data_is_too_small(void)
DS> +{
DS> +    printk(KERN_ERR "hh_data_is_too_small\n");
DS> +}

My misunderstanding. Sorry.

DS>
DS> We don't define the function because it is meant to
DS> cause a compile time error if hh->hh_data is too small to
DS> hold the full p80211_data_header structure.  Please undo
DS> this change.
DS>
DS> And therefore undo this change too:
DS>
DS> - if (sizeof(hh->hh_data) < sizeof(*p))
DS> + if (sizeof(hh->hh_data) < sizeof(*p)) {
DS>    hh_data_is_too_small();
DS> +        return -1;
DS> +    }

As above.

DS>
DS> Next, what's this?
DS>
DS> - dev->hard_header = p80211_header;
DS> + dev->hard_header     = p80211_header;
DS>   dev->rebuild_header  = p80211_rebuild_header;
DS>
DS> Your merely changing the tab character after dev->hard_header
DS> into spaces.  Please don't do this.  This makes a lot of white
DS> space noise when making diffs against the original davem-p80211
DS> code thus making it harder to review the changes you actually made.

My editor did it for me. I'll be more carefull to check this behind the scene 
things. Maybe, I'll do one patch to do all spaces accordingly to kernel 
coding style, and since that will follow it.

DS>
DS> Next:
DS>
DS> +    dev->mtu                = 2304;
DS> +    dev->type               = ARPHRD_IEEE80211;
DS>
DS> Is this really the correct default MTU for wireless devices?

Yes, 802.11e (QoS) defines this value.

DS>
DS> @@ -342,7 +343,7 @@ int p80211_recv_cfackpoll(struct sk_buff
DS>  static struct packet_type p80211_packet_type = {
DS>   .type = __constant_htons(ETH_P_802_11),
DS>   .func = p80211_rcv,
DS> - .data = (void *) 1, /* understands shared SKBs */
DS> + .af_packet_priv = (void *) 1, /* understands shared SKBs */
DS>  };
DS>
DS> You can just remove this line entirely for 2.6.x kernels.

Thanks, I will. I was confused by this member and did simplest trick to make 
it compile.

DS>
DS> Otherwise looks fine :-)

Really, thus far I did almost nothing. It is just foundation for playing with 
stack. My intention was to decouple driver and stack ASAP to enable separate 
development for each part.

Next step I will do data path, with some code to enable QoS 26 byte headers 
but without real QoS, which is, by the way, pretty complicated as defined in 
TGe. May be, it is better to start with WME w.r.t QoS.

Then, it is management's turn. Association, scanning.

Then, once again, data path. Fragmentation, reassembly. Framework for 
security.

Then - let's see how this will develop.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: generic 802.11 stack

[David S. Miller]

On Sat, 2 Oct 2004 01:25:32 +0200
Vladimir Kondratiev <vkondra@mail.ru> wrote:

> DS> Next:
> DS>
> DS> +    dev->mtu                = 2304;
> DS> +    dev->type               = ARPHRD_IEEE80211;
> DS>
> DS> Is this really the correct default MTU for wireless devices?
> 
> Yes, 802.11e (QoS) defines this value.

All existing wireless drivers use the standard ethernet MTU.
I really think it is supposed to be 1500.

That's why I left it at ether_setup()'s setting.

Upper layers really want to see a 1500 byte standard ethernet
MTU by default.  It's OK to let people set this higher via
netdev->change_mtu() configuration calls, but by default it
should be something that makes sense for most networks and
that is 1500.

Yes, btw, your tabs are all screwed up.  Please configure
your editor to use real tab characters.  Your's is using
spaces and using a tab-stop of 4 when it should be 8.

Re: [Acx100-devel] Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Denis Vlasenko]

On Wednesday 08 September 2004 22:51, Vladimir Kondratiev wrote:
> Greg,
> you missed one important point. Besides data packets, that every driver now
> convert .11<->.3 using almost the same code, there is whole story of
> management. Many modern cards are "softmac" and do all management on host.
> I see no point for every driver to implement its own scanning and
> association. It is simply waste of resources.

This is exactly what I meant. We need generic 802.11 idioc^W management
handling. And maybe also tx rate control, ACK/retries for "completely-softmac"
cards like Atheros.

Full spectrum of possible fullmac......softmac designs are not trivial
to handle...

> To make step forward, I suggest the following:
>
> 1. Dave's code is at least year old. someone need to start maintain it,
> starting with update for current kernel infrastructure. Get it compile and
> load for 2.6.9, for example.

/me runs away and hides

> 2. To debug stack, you don't need real driver. I can write dummy .11 driver
> that will silently discard all Tx, and will provide some way for user level
> tool to simulate Rx (ioctl, netlink, does not really matter). For logic, it
> is sufficient. Later, when it will come to timing, performance etc, it will
> be easy to strip some real driver.
--
vda

Re: [Acx100-devel] Re: [RFC] acx100 inclusion in mainline; generic 802.11 stack

[Sam Leffler]

On Sep 8, 2004, at 2:19 PM, Denis Vlasenko wrote:

> On Wednesday 08 September 2004 22:51, Vladimir Kondratiev wrote:
>> Greg,
>> you missed one important point. Besides data packets, that every 
>> driver now
>> convert .11<->.3 using almost the same code, there is whole story of
>> management. Many modern cards are "softmac" and do all management on 
>> host.
>> I see no point for every driver to implement its own scanning and
>> association. It is simply waste of resources.
>
> This is exactly what I meant. We need generic 802.11 idioc^W management
> handling. And maybe also tx rate control, ACK/retries for 
> "completely-softmac"
> cards like Atheros.

The net80211 code has generic 802.11 management handling based on 
wireless extensions.  Drivers that sit beneath it and have the 
necessary capabilities automatically are usable, for example, with 
wpa_supplicant (and soon hostapd).  At the moment there is one driver 
for Linux--the ath driver for Atheros h/w.

Rate control is another can-o-worms.  The model we've taken is that it 
is driver-specific.

I'd be very surprised to see "softmac" h/w come along that requires the 
host to generate ACK frames explicitly; the timing is very tight and it 
would suck a lot of cycles from the host.

>
> Full spectrum of possible fullmac......softmac designs are not trivial
> to handle...

Experience with net80211 indicates you're fine if you have a good 
802.11 protocol implementation to fall back on.  Then devices that have 
functionality in h/w just supplant the s/w support.  The net80211 code 
defines a set of device capabilities that indicate, for example, when a 
device supports various h/w crypto algorithms.  Class-like method 
override mechanisms are used to handle other issues.

This stuff is constantly evolving as more devices are hooked up but in 
general it's worked out pretty well.  I've tried to avoid a spaghetti 
web of function pointers using callbacks only where it seems most 
drivers will make use of them.  For other cases it often is easier to 
grab control early on so it's easier to optimize+share code.  A 
concrete example of this is the processing of 802.11 management frames 
where the original code (that David saw) had an array of function 
pointers to little routines that handled each frame type--it turned out 
drivers didn't override these pointers  so I removed them and drivers 
that want to override the default processing override the "recv 
management" method to intercept specific frames.

>
>> To make step forward, I suggest the following:
>>
>> 1. Dave's code is at least year old. someone need to start maintain 
>> it,
>> starting with update for current kernel infrastructure. Get it 
>> compile and
>> load for 2.6.9, for example.
>
> /me runs away and hides
>
>> 2. To debug stack, you don't need real driver. I can write dummy .11 
>> driver
>> that will silently discard all Tx, and will provide some way for user 
>> level
>> tool to simulate Rx (ioctl, netlink, does not really matter). For 
>> logic, it
>> is sufficient. Later, when it will come to timing, performance etc, 
>> it will
>> be easy to strip some real driver.

To evaluate a design and implementation show support for a few devices 
at each end of the spectrum.  The Atheros h/w is probably a good 
example of softmac h/w.  ADMTek 8211 is also in this category.  I'd 
consider Prism devices toward the other end.  You also need to be sure 
you handle single- and dual-band operation as each have different 
requirements.  Also 11g support takes work to get right so be sure you 
have a softmac 11g card in the pile.  Past that you get into the 
security protocols, WME/WMM, etc.

Sound like a lot of work?  It is.

	Sam