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.
pgpdj10STxHrF.pgp
Description: PGP signature
