Re: wireless: recap of current issues (other issues)

[Stuffed Crust <pizza@shaftnet.org>]

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

On Sat, Jan 14, 2006 at 05:09:23PM -0500, Jeff Garzik wrote:
> A big open issue:  should you fake ethernet, or represent 802.11 
> natively throughout the rest of the net stack?
> 
> The former causes various and sundry hacks, and the latter requires that 
> you touch a bunch of non-802.11 code to make it aware of a new frame class.

Internally, we're pure 802.11.  One thing to keep in mind that we're not 
going to be bridging/translating non-data traffic to other networks, and 
with that in mind, 802.3<->802.11 translation is trivial, and won't lose 
anything except for a bit of efficiency.  (and then, just to be 
contrary, the prism54 hardware actually requires 802.3 frames!)

That said.. we need to make the rest of the stack 802.11-aware.  
Translating between 802.11 and 802.3 is trivial, as we only need to know 
about a few operating parameters in order to perform the conversion -- 
AP/STA mode, BSSID, QoS parametsrs. WDS link parameters.   All of these 
can be attached to the net_device to be used by the hard_header code.

(Part of the problem is that 802.11 has a variable-length header - 24,
 26, 30, or 32 bytes, and each address field means different things 
 depending on which mode we're using..)

Meanwhile, A current "good enough for most" solution is to make all
"data" interfaces to the 802.11 stack appear as 802.3 interfaces.  Each
of these net_devices could translate to/from 802.11 on the fly.  Thus 
internally the stack would be pure 802.11, but interacting with the 
outside world would depend on the "mode" of the net_device.   You want 
to tx/rx 802.11 management frames with QoS enabled?  Create a "type 
802_11_a3_qos" inteface. 

 - Solomon
-- 
Solomon Peachy        				 ICQ: 1318344
Melbourne, FL 					 
Quidquid latine dictum sit, altum viditur.

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