From: John W. Linville <hidden> Date: 2006-01-13 22:24:19
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
linville@tuxdriver.com
From: Johannes Berg <johannes@sipsolutions.net> Date: 2006-01-13 22:35:19
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
From: Johannes Berg <johannes@sipsolutions.net> Date: 2006-01-13 23:02:12
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:
quoted
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
From: Jeff Garzik <hidden> Date: 2006-01-14 22:09:27
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
From: John W. Linville <hidden> Date: 2006-01-15 00:55:27
On Sat, Jan 14, 2006 at 05:09:23PM -0500, Jeff Garzik wrote:
John W. Linville wrote:
quoted
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
linville@tuxdriver.com
From: "David S. Miller" <davem@davemloft.net> Date: 2006-01-15 01:56:07
From: Jeff Garzik <redacted>
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.
From: Arnaldo Carvalho de Melo <hidden> Date: 2006-01-15 11:23:31
On 1/14/06, David S. Miller [off-list ref] wrote:
From: Jeff Garzik <redacted>
Date: Sat, 14 Jan 2006 17:09:23 -0500
quoted
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 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.
From: Stefan Rompf <hidden> Date: 2006-01-17 23:38:03
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.