Other Issues
============
Radiotap headers make sense for an rfmon virtual device. I don't
think it makes sense for "normal" usage. Should there be an option
for radiotap headers on non-rfmon links?
Rfmon interferes w/ other interfaces, but may be handy to enter/leave
w/ little effort. Perhaps a config option for physical device to
suspend/resume all (non-rfmon) virtual devices before/after enabling
rfmon virtual device? (Would multiple rfmon devices even make sense?
If not, is it worth restricting that?)
What about old hardware w/ inactive maintenance? Deprecate/remove?
Grandfather them w/ treatment as ethernet devices? Probably don't
need a pronouncement on this at this time...
--
John W. Linville
[email protected]
On Fri, 2006-01-13 at 17:24 -0500, John W. Linville wrote:
> Radiotap headers make sense for an rfmon virtual device. I don't
> think it makes sense for "normal" usage. Should there be an option
> for radiotap headers on non-rfmon links?
Yes. For hardware debugging.
> Rfmon interferes w/ other interfaces, but may be handy to enter/leave
> w/ little effort. Perhaps a config option for physical device to
> suspend/resume all (non-rfmon) virtual devices before/after enabling
> rfmon virtual device? (Would multiple rfmon devices even make sense?
> If not, is it worth restricting that?)
Multiple rfmon devices make sense in hypothetical or future hardware if
different channels are supported on one WiPHY at once, but the rfmon
device shall be restricted to a single one. Since we probably need a way
to deactivate virtual devices anyway, having a config option to
suspend/resume all others doesn't make sense -- userspace programs can
just as well cycle over them and do it themselves.
johannes
On Fri, 2006-01-13 at 23:35 +0100, Johannes Berg wrote:
> On Fri, 2006-01-13 at 17:24 -0500, John W. Linville wrote:
>
> > Radiotap headers make sense for an rfmon virtual device. I don't
> > think it makes sense for "normal" usage. Should there be an option
> > for radiotap headers on non-rfmon links?
>
> Yes. For hardware debugging.
Actually, scratch that. For hardware debugging you just add a virtual
rfmon device and go with that, and just don't do anything except 2
virtual devices on the wiphy.
johannes
John W. Linville wrote:
> Other Issues
> ============
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.
Jeff
On Sat, Jan 14, 2006 at 05:09:23PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:
> >Other Issues
> >============
>
> 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.
I had this entry in the "compatibility" section:
We need to be an 802.11 stack (i.e. drivers need to handle 802.11
frames). Ethernet emulation is bound to paint us into a corner
eventually (if it hasn't already)
My opinion is that we need to 'bite the bullet' and make the kernel
aware of 802.11. I figure we can leverage some existing work by
davem and acme for this.
John
--
John W. Linville
[email protected]
From: Jeff Garzik <[email protected]>
Date: Sat, 14 Jan 2006 17:09:23 -0500
> 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.
The former, most importantly, can cause the packet to get copied.
Actually, this depends upon how you implement things and when the
header change occurs.
My vote is for making the whole of the networking 802.11 frame class
aware.
On 1/14/06, David S. Miller <[email protected]> wrote:
> From: Jeff Garzik <[email protected]>
> Date: Sat, 14 Jan 2006 17:09:23 -0500
>
> > 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.
>
> The former, most importantly, can cause the packet to get copied.
> Actually, this depends upon how you implement things and when the
> header change occurs.
>
> My vote is for making the whole of the networking 802.11 frame class
> aware.
Agreed :-)
- Arnaldo
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.
To fake ethernet or not?
------------------------
There is a similar problem in the VLAN code - do you expect the rest of
the network stack to be able to interpret VLAN tagged frames? This was
the original state of the VLAN code - this caused problems since many
apps and modules did not understand VLAN tags (e.g. dhcp). The VLAN
code was extended to offer both options - the VLAN virtual device can
be switched to ethernet (non tagged) or tagged. I would suggest that for
compatibility the default for WLAN code be ethernet format frames, and
if somebody wants it to also have an option for 802.11 format frames -
then that be alowed too. If you really want to build a kernel without
ethernet support this is theoretically possible.
The 802.11 format question is related to the 'virtual devices' question.
Most 802.11 implementations split into 2 categories. 1. Those where the
MLME runs on the chip and 2. those where the MLME runs in the host. The
MLME implementations that run on the chip to date that I know about do
not support multiple virtual networks, or other advanced features that
require multiple virtual devices. For these devices frames are typically
exchanged with the hardware in ethernet format, and a single ethernet
format net_device is likely all that will be needed in linux. For
devices that leave the MLME to the host, a much wider range of advanced
features is possible - and here a raw 802.11 net_device and multiple
virtual devices is likely required. A single physical device is required
to implement a qdisc and do priority queueing properly. Multiple virtual
devices to support advanced stack features could be either 802.11 format
or ethernet format depending on the feature and configuration.
Channels/Frequencies
--------------------
For chips with firmware that runs on the chip oftentimes the setting of
channel and power limits is done on the chip, in order to meet the FCC
restriction of making it difficult for the end user to set illegal
values. In cases of chips without firmware these functions may be done
by the stack, or in some cases by a binary code block.
Simon
-----Original Message-----
From: [email protected] [mailto:[email protected]]
On Behalf Of Jeff Garzik
Sent: Saturday, January 14, 2006 2:09 PM
To: John W. Linville
Cc: [email protected]; [email protected]
Subject: Re: wireless: recap of current issues (other issues)
John W. Linville wrote:
> Other Issues
> ============
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.
Jeff
Am Sonntag 15 Januar 2006 16:39 schrieb Stuffed Crust:
> 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!)
prism2 usb is even worse - the urb is build of some control structure, the
802.11 3 address header, a 802.3 header and the 802.11 data part. Some bits
in the control structure decide whether the 802.11 or the 802.3 header is
used to create the frame sent to the air.
Fortunately, a driver should be able to specify it's additional memory need at
the front of the frame via hard_header_len. Some drivers will need to do some
ugly memmove()s at the packet begin then.
> (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..)
.. and it gets even worse as soon as we start encrypting packets. I think we
should start using the netdev wiki at http://linux-net.osdl.org/ to collect
information. For this part of the discussion, we need to know what transmit
frame formats different hardware needs.
I'll ask Stephen Hemminger to put a link for wireless development on the index
page and will start with frame information for prism2 and other hardware I
have and understand good enough.
Stefan
On Wed, Jan 18, 2006 at 12:36:09AM +0100, Stefan Rompf wrote:
> prism2 usb is even worse - the urb is build of some control structure, the
> 802.11 3 address header, a 802.3 header and the 802.11 data part. Some bits
> in the control structure decide whether the 802.11 or the 802.3 header is
> used to create the frame sent to the air.
I actually maintain a prism2 usb driver. It's host interface is truly
fscked, and then there are the unfixable hardware bugs... But back to
your point -- It's actually true of all prism2 devices. You can use one
header or the other, but space for both is part of the fixed packet
structure.
Meanwhile, I've only seen one wireless chipset that *requires* 802.3
headers, and that is the prism54/prismGT/Indigo/Duette (FullMAC mode).
Those adapters (except for the Indigo, which never made it into
production anyway) can run in a softmac mode, which uses regular 802.11
headers.
It's actually fairly common that hardware devices have the 802.11 header
separated from the 802.11 payload slightly, if for no other reason that
they need space to add the encryption headers. You can't make any
assumptions.
> Fortunately, a driver should be able to specify it's additional memory need at
> the front of the frame via hard_header_len. Some drivers will need to do some
> ugly memmove()s at the packet begin then.
This amount also varies with different encryption modes. And don't
forget you also need space for an LLC+SNAP header and finally, you need
a frame footer for encryption as well.
> .. and it gets even worse as soon as we start encrypting packets. I think we
> should start using the netdev wiki at http://linux-net.osdl.org/ to collect
> information. For this part of the discussion, we need to know what transmit
> frame formats different hardware needs.
They're all over the map, yes.. there's no guarantee that the frame will
be contiguious. It's annoying.. They also vary depending on encrpytion
mode. Keep the 802.11 stack generic; split the packet into its logical
block.
On a per-frame basis, you have:
- 802.11 header (variable length)
- Encryption header (variable length)
- LLC+SNAP header on payload (which we may need to add)
- actual payload
- Encryption footer (variable length)
How's this strawman proposal:
wiphy_frame_xmit (struct wiphy_dev *dev, struct sk_buff *skb);
skb->data points to the raw payload, with LLC+SNAP header.
skb->cb points to a structure that has, among other things:
- 802.11 header + length
- encryption header + length
- encryption footer + length
- desired data rate(s), antenna, rts/cts, and other tx params.
- hw/sw encryption flag, and the key needed to encrypt.
Given that I haven't seen two chipsets that do thigns the same way,
there's little point in making the stack generic enough to rearrange
these bits in the correct places. That said, we could provide a generic
coalesce method for the general swcrypto+payload case, where the
hardware would presumably treat it as an opaque payload.
Each driver would be responsible for rearranging these chunks as
appropriate, ideally using scatter-gather DMA. That's why the chunks
are all specified as chunk+len; the driver can blindly copy the chunks
without worrying about their contents.
Chipsets that require payload padding when using crypto can tell the
802.11 stack of this requirement, and the stack will pass the
appropriate pads in via the crypt_header and crypt_footer.
I've put this stuff on the wiki, for what it's worth.
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.