* RE: wireless: recap of current issues (other issues)
@ 2006-01-16 5:32 Simon Barber
0 siblings, 0 replies; 9+ messages in thread
From: Simon Barber @ 2006-01-16 5:32 UTC (permalink / raw)
To: Jeff Garzik, John W. Linville; +Cc: netdev, linux-kernel
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: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Jeff Garzik
Sent: Saturday, January 14, 2006 2:09 PM
To: John W. Linville
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org
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
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20060113195723.GB16166@tuxdriver.com>]
* wireless: recap of current issues (intro) [not found] <20060113195723.GB16166@tuxdriver.com> @ 2006-01-13 21:26 ` John W. Linville [not found] ` <20060113213237.GH16166@tuxdriver.com> 0 siblings, 1 reply; 9+ messages in thread From: John W. Linville @ 2006-01-13 21:26 UTC (permalink / raw) To: netdev Cc: linux-kernel, Jiri Benc, Stefan Rompf, Mike Kershaw, Krzysztof Halasa, Robert Hancock, Alistair John Strachan, Dominik Brodowski, Denis Vlasenko, Danny van Dyk, Stephen Hemminger, feyd, Chase Venters, Andreas Mohr, Bas Vermeulen, Jean Tourrilhes, Daniel Drake, Ulrich Kunitz, Phil Dibowitz, Simon Kelley, Michael Buesch, Marcel Holtmann, Patrick McHardy, Ingo Oeser, Harald Welte, Ben Greear, Thomas Graf My original post got eaten by the lists -- probably too big... I'm reposting in sections. After this intro follow sections on Configuration, Compatibility, Stack, Other Issues, and Actions. Enjoy! :-) --- WiFi-ers... Here I am, still feeling "up to the challenge"... I have stopped hyper-ventilating and the nervous vomiting is all over... :-) Having accepted the wireless role, I wanted to review the discussions prompted by Jeff's "State of the Union" message from a little over a week ago. There is lots of good talent involved in these discussions, and I believe a surprisingly high level of agreement (some of it nearly violent!) amongst the players. Below I have recapped what I saw as most of the important issues. I have endorsed some of the ideas, mostly those which seem to have broad agreement. I have also thrown-out a few ideas of my own. Please do comment on all of them, as neither my summaries nor my original ideas are likely to be without fault. :-) I have primarily grouped the issues into configuration, compatibility, and stack concerns. I also included an "other" group for a few other concerns that I though were worth mentioning. Finally, I have included an "actions" section to reveal some of my near-term plans and some of what I am thinking about beyond that. I would love to hear any comments you might have on these items as well. Thanks for taking the time to look this over. Creating this recap has reinforced one thing: this is far too big for just a single person (or even a small group) to tackle alone! Thanks, John -- John W. Linville linville@tuxdriver.com ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20060113213237.GH16166@tuxdriver.com>]
* wireless: recap of current issues (other issues) [not found] ` <20060113213237.GH16166@tuxdriver.com> @ 2006-01-13 22:24 ` John W. Linville 2006-01-13 22:35 ` Johannes Berg 2006-01-14 22:09 ` Jeff Garzik 0 siblings, 2 replies; 9+ messages in thread From: John W. Linville @ 2006-01-13 22:24 UTC (permalink / raw) To: netdev; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: wireless: recap of current issues (other issues) 2006-01-13 22:24 ` wireless: recap of current issues (other issues) John W. Linville @ 2006-01-13 22:35 ` Johannes Berg 2006-01-13 23:02 ` Johannes Berg 2006-01-14 22:09 ` Jeff Garzik 1 sibling, 1 reply; 9+ messages in thread From: Johannes Berg @ 2006-01-13 22:35 UTC (permalink / raw) To: netdev; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1029 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: wireless: recap of current issues (other issues) 2006-01-13 22:35 ` Johannes Berg @ 2006-01-13 23:02 ` Johannes Berg 0 siblings, 0 replies; 9+ messages in thread From: Johannes Berg @ 2006-01-13 23:02 UTC (permalink / raw) To: netdev; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 533 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: wireless: recap of current issues (other issues) 2006-01-13 22:24 ` wireless: recap of current issues (other issues) John W. Linville 2006-01-13 22:35 ` Johannes Berg @ 2006-01-14 22:09 ` Jeff Garzik 2006-01-15 0:54 ` John W. Linville ` (2 more replies) 1 sibling, 3 replies; 9+ messages in thread From: Jeff Garzik @ 2006-01-14 22:09 UTC (permalink / raw) To: John W. Linville; +Cc: netdev, linux-kernel 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: wireless: recap of current issues (other issues) 2006-01-14 22:09 ` Jeff Garzik @ 2006-01-15 0:54 ` John W. Linville 2006-01-15 1:51 ` David S. Miller 2006-01-15 15:39 ` Stuffed Crust 2 siblings, 0 replies; 9+ messages in thread From: John W. Linville @ 2006-01-15 0:54 UTC (permalink / raw) To: Jeff Garzik; +Cc: netdev, linux-kernel 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 linville@tuxdriver.com ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: wireless: recap of current issues (other issues) 2006-01-14 22:09 ` Jeff Garzik 2006-01-15 0:54 ` John W. Linville @ 2006-01-15 1:51 ` David S. Miller 2006-01-15 11:23 ` Arnaldo Carvalho de Melo 2006-01-15 15:39 ` Stuffed Crust 2 siblings, 1 reply; 9+ messages in thread From: David S. Miller @ 2006-01-15 1:51 UTC (permalink / raw) To: jgarzik; +Cc: linville, netdev, linux-kernel From: Jeff Garzik <jgarzik@pobox.com> 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: wireless: recap of current issues (other issues) 2006-01-15 1:51 ` David S. Miller @ 2006-01-15 11:23 ` Arnaldo Carvalho de Melo 0 siblings, 0 replies; 9+ messages in thread From: Arnaldo Carvalho de Melo @ 2006-01-15 11:23 UTC (permalink / raw) To: David S. Miller; +Cc: jgarzik, linville, netdev, linux-kernel On 1/14/06, David S. Miller <davem@davemloft.net> wrote: > From: Jeff Garzik <jgarzik@pobox.com> > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: wireless: recap of current issues (other issues) 2006-01-14 22:09 ` Jeff Garzik 2006-01-15 0:54 ` John W. Linville 2006-01-15 1:51 ` David S. Miller @ 2006-01-15 15:39 ` Stuffed Crust 2 siblings, 0 replies; 9+ messages in thread From: Stuffed Crust @ 2006-01-15 15:39 UTC (permalink / raw) To: Jeff Garzik; +Cc: John W. Linville, netdev, linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2006-01-16 5:32 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-01-16 5:32 wireless: recap of current issues (other issues) Simon Barber [not found] <20060113195723.GB16166@tuxdriver.com> 2006-01-13 21:26 ` wireless: recap of current issues (intro) John W. Linville [not found] ` <20060113213237.GH16166@tuxdriver.com> 2006-01-13 22:24 ` wireless: recap of current issues (other issues) John W. Linville 2006-01-13 22:35 ` Johannes Berg 2006-01-13 23:02 ` Johannes Berg 2006-01-14 22:09 ` Jeff Garzik 2006-01-15 0:54 ` John W. Linville 2006-01-15 1:51 ` David S. Miller 2006-01-15 11:23 ` Arnaldo Carvalho de Melo 2006-01-15 15:39 ` Stuffed Crust
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).