wireless: recap of current issues (intro)

wireless: recap of current issues (intro)

[John W. Linville]

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

wireless: recap of current issues (intro)

[John W. Linville]

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

wireless: recap of current issues (configuration)

[John W. Linville]

Configuration
=============

Configuration seems to be coalescing around netlink.  Among other
things, this technology provides for muliticast requests and
asynchronous event notification.

The kernel should provide generic handlers for netlink
configuraion messages, and there should be a per-device 80211_ops
(wireless_ops? akin to ethtool_ops) structure for drivers to
populate appropriately.

At init, physical devices should be represented by a "WiPHY" device,
not directly by a net_device.  The list of physical devices should
be discoverable through netlink and/or sysfs.  (A WiPHY device is an
abstraction representing the radio interface itself.)

Virtual wlan devices should be associated to a WiPHY device many-to-one
(one-to-one for some devices).  Virtual devices correspond to a net_device.

Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
raw?, other modes?) which defines its "on the air" behaviour.  Should
this mode be fixed when the wlan device is created?  Or something
that can be changed when the net_device is down?

It may be necessary to remove, suspend, and/or disable wlan devices
in order to add, resume, and/or enable other types of wlan devices
on the same WiPHY device (especialy true for rfmon).  A mechanism is
needed for drivers to be able to influence or disallow combinations
of wlan devices in accordance with capabilities of the hardware.

Do "global" config requests go to any associated wlan device?
Or must they be directed to the WiPHY device?  Does it matter?
I think we should require "global" configuration to target the WiPHY
device, while "local" configuration remains with the wlan device.
(I'm not sure how important this point is?)  Either way, the WiPHY
device will need some way to be able to reject configuration requests
that are incompatible among its associated wlan devices.  Since the
wlan interface implementations should not be device specific, perhaps
the 802.11 stack can be smart enough to filter-out most conflicting
config requests before they get to the WiPHY device?
-- 
John W. Linville
linville@tuxdriver.com

Re: wireless: recap of current issues (configuration)

[Johannes Berg]

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

[since none our replies made it to the lists, here mine are again.
apologies to those who see it twice, just skip it, I only pasted my
previous replies]

> Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
> raw?, other modes?) which defines its "on the air" behaviour.  Should
> this mode be fixed when the wlan device is created?  Or something
> that can be changed when the net_device is down?

IMHO there's not much point in allowing changes. I have a feeling that
might create icky issues you don't want to have to tackle when the
solution is easy by just not allowing it. Part of my thinking is that
different virtual types have different structures associated, so
changing it needs re-creating structures anyway. And different virtual
device types might even be provided by different kernel modules so you
don't carry around AP mode if you don't need it.

> Do "global" config requests go to any associated wlan device?
> Or must they be directed to the WiPHY device?  Does it matter?
> I think we should require "global" configuration to target the WiPHY
> device, while "local" configuration remains with the wlan device.
> (I'm not sure how important this point is?)

Right [global config targets wiphy]. I do think this is an important UI
issue that userspace will have to tackle, but I think the correct way
for the kernel is to surface this issue instead of creating workarounds.

> Either way, the WiPHY
> device will need some way to be able to reject configuration requests
> that are incompatible among its associated wlan devices.  Since the
> wlan interface implementations should not be device specific, perhaps
> the 802.11 stack can be smart enough to filter-out most conflicting
> config requests before they get to the WiPHY device?

I'm not sure this is worth it. While putting this into the WiPHY device
creates more logic there, putting knowledge like 'how many different
channels can this WiPHY device support' etc. into some representation
that can be used by the stack to decide is much more trouble than it is
worth.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Fri, Jan 13, 2006 at 11:32:02PM +0100, Johannes Berg wrote:
> I'm not sure this is worth it. While putting this into the WiPHY device
> creates more logic there, putting knowledge like 'how many different
> channels can this WiPHY device support' etc. into some representation
> that can be used by the stack to decide is much more trouble than it is
> worth.

Do you mean 'simultaneous' channel operation, or something more mundane 
like simply 'what frequencies can I run on'?

If you're talking about the former.. things get quite complicated, but 
that could be handled by having two WiPHY devices registered.

As for the latter, when you factor in the needs of 802.11d and its
dependents (802.11j, 802.11k, and others) the stack is going to need to
be aware of the available channel sets; both in the sense of hardware
support and also the various regulatory requirements. 

The hardware knows what frequencies it supports.  Unfortunately this has 
to be a somewhat dynamic thing, as this is often not queryable until the 
device firmware is up and running.  

This can be accomplished by passing a static table to the 
register_wiphy_device() call (or perhaps via a struct wiphy_dev 
parameter) or through a more explicit, dynamic interface like:

  wiphy_register_supported_frequency(hw, 2412). 

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

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

Re: wireless: recap of current issues (configuration)

[Johannes Berg]

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

On Fri, 2006-01-13 at 20:17 -0500, Stuffed Crust wrote:

> If you're talking about the former.. things get quite complicated, but 
> that could be handled by having two WiPHY devices registered.

The former; and yes, I thought about that too -- having a driver that
shows two physical WiPHY devices as a single logical WiPHY device and
distributes virtual devices among them...

> As for the latter, when you factor in the needs of 802.11d and its
> dependents (802.11j, 802.11k, and others) the stack is going to need to
> be aware of the available channel sets; both in the sense of hardware
> support and also the various regulatory requirements. 
> 
> The hardware knows what frequencies it supports.  Unfortunately this has 
> to be a somewhat dynamic thing, as this is often not queryable until the 
> device firmware is up and running.  
> 
> This can be accomplished by passing a static table to the 
> register_wiphy_device() call (or perhaps via a struct wiphy_dev 
> parameter) or through a more explicit, dynamic interface like:
> 
>   wiphy_register_supported_frequency(hw, 2412). 

Yeah, this is about what I thought of -- and it makes me wonder if the
stack really should be aware of the channelization, or if the WiPHY
driver might better just handle it itself.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: wireless: recap of current issues (configuration)

[Krzysztof Halasa]

Johannes Berg <johannes@sipsolutions.net> writes:

> Yeah, this is about what I thought of -- and it makes me wonder if the
> stack really should be aware of the channelization, or if the WiPHY
> driver might better just handle it itself.

The latter, possibly using library functions from the stack :-)
-- 
Krzysztof Halasa

Re: wireless: recap of current issues (configuration)

[Jeff Garzik]

Stuffed Crust wrote:
> The hardware knows what frequencies it supports.  Unfortunately this has 
> to be a somewhat dynamic thing, as this is often not queryable until the 
> device firmware is up and running.  
> 
> This can be accomplished by passing a static table to the 
> register_wiphy_device() call (or perhaps via a struct wiphy_dev 
> parameter) or through a more explicit, dynamic interface like:
> 
>   wiphy_register_supported_frequency(hw, 2412). 


For completely programmable hardware, the stack should interact with a 
module like ieee80211_geo, to help ensure the hardware stays within 
legal limits.

	Jeff

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
> >This can be accomplished by passing a static table to the 
> >register_wiphy_device() call (or perhaps via a struct wiphy_dev 
> >parameter) or through a more explicit, dynamic interface like:
> >
> >  wiphy_register_supported_frequency(hw, 2412). 
> 
> For completely programmable hardware, the stack should interact with a 
> module like ieee80211_geo, to help ensure the hardware stays within 
> legal limits.

While there is much to debate about where to draw the functionality 
line, completely programmable hardware is the norm these days.

... and said code would be responsible for driving the scanning state
machines, and also for more esoteric functions like handling RADAR
traps, automatic channel switching, etc.

Handling scans is quite interesting -- I've seen hardware which requires 
manual channel changing (including full RF parameter specification), 
host timing for the channel dwell time, and manual probe request 
issuance.. and on the other end of the spectrum, a simple "issue scan" 
command that takes few, if any, parameters.

And unfortunately, many things in between.

This leads me to belive that the internal scan workflow should work
something like this:

 * Userspace app issues scan request (aka "refresh AP list")

 * Knowing the hardware frequency capabilities, the 802.11 stack applies 
   802.11d and regdomain rules to the available frequency set, and
   issues multiple internal "scan request" commands to the hardware 
   driver.  (eg "perform an initial passive sweep across the entire 
   2.4G band", "perform an active scan on frequencies 2412->2437 
   looking for ssid "HandTossed", "perform an active scan on 
   frequencies 5200-5400 looking for ssid "HandTossed", etc)

   (note that ideally, userspace apps/libs would be at least partially
    aware of 802.11d rules, but the kernel must do the RightThing if 
    told to "scan all available channels for any access points")
  
 * The hardware driver takes this scan request, and maps it into the 
   capabilities of the hardware:

   Hardware A: (very thin MAC)
    - Using library code, generates an appropriate probe request frame, 
      translates it into a format the hardware expects/needs, 
      and schedules it appropriately.
    - Loops through the frequency set specified, and for each:
	- Issues a channel change command
	- Immediately transmits the probe request (for active scans)
	- Dwells for an appropriate time
        - RX'ed beacon/probe response frames come down as regular 802.11 
          frames into the stack
        - Moves to the next channel

   Hardware B: (thinner MAC)
    - Using library code, generates an appropriate probe request frame, 
      and translate it into a format the hardware expects.
    - Program the probe request frame into the hardware as a probe 
      template.
    - Loops through the frequency set specified, and for each:
	- Issues a channel change command
        - Wait for a scan complete signal
        - RX'ed beacon/probe response frames come down as regular 802.11 
          frames into the stack
        - Moves to the next channel
    
   Hardware C: (thick MAC, ala prism2 or prism54)
     - Issues a hardware "scan request"
     - Waits for the hardware to signal "scan complete"
     - Requests hardware scan results
     - For each scan result, the hardware returns:
        - Translate result into an 802.11 probe response frame and
          pass down the regular RX path.

   So as you can see, I think the channel iteration, dwell, etc should 
   be performed by the hardware driver itself, as the variation at the 
   logical "tell the hardware perform a scan" step is so extreme.

 * Meanwhile, the 802.11 stack is receiving the beacons/probe responses 
   from the hardware via the regular rx path.  It diverts these (and 
   other 802.11 management/control) frames, decodes them, and then adds 
   them to the stack's internal list of available stations, updating any 
   internal states/counters as necessary.  (These frames could also be 
   echoed to a special netdev interface if desired)

   (stuff like detecting an AP going away depends on us noticing a lack 
    of beacons arriving, for example.  Most hardware does not 
    notify us of this event.  Likewise, we should expire other 
    APs from our list if they go away.. etc.  For AP operation we need 
    to maintain this STA list, period -- so why not use it across the 
    board?  But this is another discussion for another time..)

 * The 802.11 stack issues a MLME-Scan-Complete notification to 
   userspace.

 * Interested userspace apps see this event, then query the 
   scan results and presents them to the user in some pretty format, or 
   alternatively perform automatic roaming based on scan results.

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

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

Re: wireless: recap of current issues (configuration)

[Samuel Ortiz]

On Sun, 15 Jan 2006, ext Stuffed Crust wrote:

>  * Knowing the hardware frequency capabilities, the 802.11 stack applies
>    802.11d and regdomain rules to the available frequency set, and
Regarding 802.11d and regulatory domains, the stack should also be able to
stick to one regulatory domain if asked so by userspace, whatever the APs
around tell us.

Cheers,
Samuel.

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> Regarding 802.11d and regulatory domains, the stack should also be able to
> stick to one regulatory domain if asked so by userspace, whatever the APs
> around tell us.

...and in doing so, violate the local regulatory constraints.  :)

Although I believe 802.11d specifies that the 802.11d beacons should 
trump whatever the user specifies.  (of course, 802.11d doesn't say what 
to do when there are APs out there that disagree...)

While I feel it should be *posisble* to do so, the default should be to
query the hardware for its factory default, and go with that.  Allowing
the user to change the regulatory domain at will.. is a rather fuzzy
legal area, to say the least.

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

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

Re: wireless: recap of current issues (configuration)

[Samuel Ortiz]

On Mon, 16 Jan 2006, ext Stuffed Crust wrote:

> On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > Regarding 802.11d and regulatory domains, the stack should also be able to
> > stick to one regulatory domain if asked so by userspace, whatever the APs
> > around tell us.
>
> ...and in doing so, violate the local regulatory constraints.  :)
The other option is to conform to whatever the AP you associate with
advertises. In fact, this is how it should be done according to 802.11d.
Unfortunately, this doesn't ensure local regulatory constraints compliance
unless you expect each and every APs to do the Right Thing ;-)


> Allowing
> the user to change the regulatory domain at will.. is a rather fuzzy
> legal area, to say the least.
IMHO, strictly sticking to 802.11d is also somehow legally fuzzy as you're
as legal as the network you're joining.

Cheers,
Samuel.

Re: wireless: recap of current issues (configuration)

[John W. Linville]

On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote:
> On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> 
> > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > > Regarding 802.11d and regulatory domains, the stack should also be able to
> > > stick to one regulatory domain if asked so by userspace, whatever the APs
> > > around tell us.
> >
> > ...and in doing so, violate the local regulatory constraints.  :)
> The other option is to conform to whatever the AP you associate with
> advertises. In fact, this is how it should be done according to 802.11d.
> Unfortunately, this doesn't ensure local regulatory constraints compliance
> unless you expect each and every APs to do the Right Thing ;-)

If regulators come down on someone, it seems like common sense
that they would be more lenient on mobile stations complying with a
misconfigured AP than they would be with a mobile station ignoring a
properly configured AP?  I know expecting common sense from government
regulators is optimistic, but still... :-)

Of course when we are the AP, the ability to adjust these parameters
could be very important.  No?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: wireless: recap of current issues (configuration)

[Samuel Ortiz]

On Mon, 16 Jan 2006, ext John W. Linville wrote:

> On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote:
> > On Mon, 16 Jan 2006, ext Stuffed Crust wrote:
> >
> > > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote:
> > > > Regarding 802.11d and regulatory domains, the stack should also be able to
> > > > stick to one regulatory domain if asked so by userspace, whatever the APs
> > > > around tell us.
> > >
> > > ...and in doing so, violate the local regulatory constraints.  :)
> > The other option is to conform to whatever the AP you associate with
> > advertises. In fact, this is how it should be done according to 802.11d.
> > Unfortunately, this doesn't ensure local regulatory constraints compliance
> > unless you expect each and every APs to do the Right Thing ;-)
>
> If regulators come down on someone, it seems like common sense
> that they would be more lenient on mobile stations complying with a
> misconfigured AP than they would be with a mobile station ignoring a
> properly configured AP?  I know expecting common sense from government
> regulators is optimistic, but still... :-)
Well, I'd rather trust a governement regulated network than my neighbour's
AP ;-) In fact, some phones set their 802.11 regulatory domain based on
the information they received from a somehow government regulated network,
e.g. a GSM one.

Cheers,
Samuel.

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Mon, Jan 16, 2006 at 10:16:06PM +0200, Samuel Ortiz wrote:
> Well, I'd rather trust a governement regulated network than my neighbour's
> AP ;-) In fact, some phones set their 802.11 regulatory domain based on
> the information they received from a somehow government regulated network,
> e.g. a GSM one.

The asumption is that 802.11d information, like current "regdomain"
settings, is fixed and not user-configurable.  If the regdomain is
changeable by the user, that unit would not be approved for sale in that
particular locale.

(Now 802.11d doesn't specify what to do when you hear two conflicting 
 802.11d beacons.... there go those assumptions again..)

Stations respecting 802.11d rules are not allowed to transmit on any
supported frequency until they hear an AP on that frequency first.  

This essentially means that all scans are passive until we hear an AP,
and we can't transmit on any other (presumably still silent) frequencies
unless we hear an 802.11d beacon that says we can.

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

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

Re: wireless: recap of current issues (configuration)

[Alan Cox]

On Llu, 2006-01-16 at 14:06 -0500, John W. Linville wrote:
> If regulators come down on someone, it seems like common sense
> that they would be more lenient on mobile stations complying with a
> misconfigured AP than they would be with a mobile station ignoring a
> properly configured AP?  I know expecting common sense from government
> regulators is optimistic, but still... :-)

I can't guess on the subject of US regulators but for the UK experience
in other communities (eg amateur radio), and public statements indicate
that their high priorities are interference with emergency services and
the like. 

Concerns of direct relevance are
- transmitting on unlicensed frequencies (and 802.11 channel allocations
are dependant on nation - even within the EU)
- power violation
- anything else causing interference to other legitimate users at a
radio level

I would expect equipment to honour the subset of configurations that
meet BOTH the regulatory domain the system believes it exists within
(which may change dynamically!) AND the AP advertisement.

If I have told my equipment to obey UK law I expect it to do so. If I
hop on the train to France and forget to revise my configuration I'd
prefer it also believed the APs

Alan

Re: wireless: recap of current issues (configuration)

[John W. Linville]

On Mon, Jan 16, 2006 at 10:24:41PM +0000, Alan Cox wrote:

> I would expect equipment to honour the subset of configurations that
> meet BOTH the regulatory domain the system believes it exists within
> (which may change dynamically!) AND the AP advertisement.
> 
> If I have told my equipment to obey UK law I expect it to do so. If I
> hop on the train to France and forget to revise my configuration I'd
> prefer it also believed the APs

Yes, this is an excellent point.  I suppose this could result in
a non-functional configuration, but that is probably better than
conflicting w/ the local authorities... :-)

John
-- 
John W. Linville
linville@tuxdriver.com

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Mon, Jan 16, 2006 at 10:24:41PM +0000, Alan Cox wrote:
> If I have told my equipment to obey UK law I expect it to do so. If I
> hop on the train to France and forget to revise my configuration I'd
> prefer it also believed the APs

It's not that you might forget to revise your configuration, but that 
the vast majority of users will not revise anything, and still expect 
things to "just work".  Kind of like multi-band cell phones.  

This isn't that big of a deal in the 2.4GHz band, but when you start
talking about 5GHz, especially in France, things get a lot trickier.

Of course, all of this automagic "just work" crap only affects the STAs. 
For AP operation, we have to trust the user to set the correct locale --
I don't see any way of including a sane "just-works" default in the
stock kernel.org tree, so I think the default should be be "none".  This
way the user is forced to explicitly set the regdomain in order for the
AP startup to succeed.

...and pray that the AP isn't migrating to a different regdomain, but 
there's really nothing anyone can do about that.

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

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

Re: wireless: recap of current issues (configuration)

[Kyle Moffett]

On Jan 17, 2006, at 13:41, Stuffed Crust wrote:
> On Mon, Jan 16, 2006 at 10:24:41PM +0000, Alan Cox wrote:
>> If I have told my equipment to obey UK law I expect it to do so.  
>> If I hop on the train to France and forget to revise my  
>> configuration I'd prefer it also believed the APs
>
> It's not that you might forget to revise your configuration, but  
> that the vast majority of users will not revise anything, and still  
> expect things to "just work".  Kind of like multi-band cell phones.

Alan's point is still very valid.  From a poweruser point of view, if  
I specifically tell my wireless client "You must obey US laws", and  
then I wander over past a broken imported AP, I don't want my client  
to _expand_ its allowable range.  IMHO, userspace should be able to  
forcibly restrict wireless frequencies to a certain regdomain (or  
leave unrestricted and passive-scan-only), and specify how AP/ 
configured regdomains act.  Given the range of possibilities, I think  
that a userspace daemon monitoring events and dynamically configuring  
the useable frequencies would best.  That way the userspace daemon  
could be configured to ignore APs, union/intersect the APs with the  
configured regdomain, ignore the configured regdomain in the presence  
of APs, etc.

Cheers,
Kyle Moffett

--
I lost interest in "blade servers" when I found they didn't throw  
knives at people who weren't supposed to be in your machine room.
   -- Anthony de Boer

Re: wireless: recap of current issues (configuration)

[Sam Leffler]

Stuffed Crust wrote:
> On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote:
>>> This can be accomplished by passing a static table to the 
>>> register_wiphy_device() call (or perhaps via a struct wiphy_dev 
>>> parameter) or through a more explicit, dynamic interface like:
>>>
>>>  wiphy_register_supported_frequency(hw, 2412). 
>> For completely programmable hardware, the stack should interact with a 
>> module like ieee80211_geo, to help ensure the hardware stays within 
>> legal limits.
> 
> While there is much to debate about where to draw the functionality 
> line, completely programmable hardware is the norm these days.
> 
> ... and said code would be responsible for driving the scanning state
> machines, and also for more esoteric functions like handling RADAR
> traps, automatic channel switching, etc.
> 
> Handling scans is quite interesting -- I've seen hardware which requires 
> manual channel changing (including full RF parameter specification), 
> host timing for the channel dwell time, and manual probe request 
> issuance.. and on the other end of the spectrum, a simple "issue scan" 
> command that takes few, if any, parameters.
> 
> And unfortunately, many things in between.
> 
> This leads me to belive that the internal scan workflow should work
> something like this:
> 
>  * Userspace app issues scan request (aka "refresh AP list")
> 
>  * Knowing the hardware frequency capabilities, the 802.11 stack applies 
>    802.11d and regdomain rules to the available frequency set, and
>    issues multiple internal "scan request" commands to the hardware 
>    driver.  (eg "perform an initial passive sweep across the entire 
>    2.4G band", "perform an active scan on frequencies 2412->2437 
>    looking for ssid "HandTossed", "perform an active scan on 
>    frequencies 5200-5400 looking for ssid "HandTossed", etc)
> 
>    (note that ideally, userspace apps/libs would be at least partially
>     aware of 802.11d rules, but the kernel must do the RightThing if 
>     told to "scan all available channels for any access points")
>   
>  * The hardware driver takes this scan request, and maps it into the 
>    capabilities of the hardware:
> 
>    Hardware A: (very thin MAC)
>     - Using library code, generates an appropriate probe request frame, 
>       translates it into a format the hardware expects/needs, 
>       and schedules it appropriately.
>     - Loops through the frequency set specified, and for each:
> 	- Issues a channel change command
> 	- Immediately transmits the probe request (for active scans)
> 	- Dwells for an appropriate time
>         - RX'ed beacon/probe response frames come down as regular 802.11 
>           frames into the stack
>         - Moves to the next channel
> 
>    Hardware B: (thinner MAC)
>     - Using library code, generates an appropriate probe request frame, 
>       and translate it into a format the hardware expects.
>     - Program the probe request frame into the hardware as a probe 
>       template.
>     - Loops through the frequency set specified, and for each:
> 	- Issues a channel change command
>         - Wait for a scan complete signal
>         - RX'ed beacon/probe response frames come down as regular 802.11 
>           frames into the stack
>         - Moves to the next channel
>     
>    Hardware C: (thick MAC, ala prism2 or prism54)
>      - Issues a hardware "scan request"
>      - Waits for the hardware to signal "scan complete"
>      - Requests hardware scan results
>      - For each scan result, the hardware returns:
>         - Translate result into an 802.11 probe response frame and
>           pass down the regular RX path.
> 
>    So as you can see, I think the channel iteration, dwell, etc should 
>    be performed by the hardware driver itself, as the variation at the 
>    logical "tell the hardware perform a scan" step is so extreme.
> 
>  * Meanwhile, the 802.11 stack is receiving the beacons/probe responses 
>    from the hardware via the regular rx path.  It diverts these (and 
>    other 802.11 management/control) frames, decodes them, and then adds 
>    them to the stack's internal list of available stations, updating any 
>    internal states/counters as necessary.  (These frames could also be 
>    echoed to a special netdev interface if desired)
> 
>    (stuff like detecting an AP going away depends on us noticing a lack 
>     of beacons arriving, for example.  Most hardware does not 
>     notify us of this event.  Likewise, we should expire other 
>     APs from our list if they go away.. etc.  For AP operation we need 
>     to maintain this STA list, period -- so why not use it across the 
>     board?  But this is another discussion for another time..)
> 
>  * The 802.11 stack issues a MLME-Scan-Complete notification to 
>    userspace.
> 
>  * Interested userspace apps see this event, then query the 
>    scan results and presents them to the user in some pretty format, or 
>    alternatively perform automatic roaming based on scan results.

The above is a great synopsis but there is more.  For example to support 
roaming (and sometimes for ap operation) you want to do background 
scanning; this ties in to power save mode if operating as a station. 
Further you want to order your channel list to hit the most likely 
channels first in case you are scanning for a specific ap--e.g. so you 
can stop the foreground scan and start to associate.  In terms of beacon 
miss processing some parts have a hardware beacon miss interrupt based 
on missed consecutive beacons but others require you to detect beacon 
miss in software.  Other times you need s/w bmiss detection because 
you're doing something like build a repeater when the station virtual 
device can't depend on the hardware to deliver a bmiss interrupt.

Then of course there's whole issue of interacting with firmware-based 
cards that have limited and/or funkiness in their scanning support.

Scanning (and roaming) is really a big can 'o worms.

	Sam

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote:
> The above is a great synopsis but there is more.  For example to support 
> roaming (and sometimes for ap operation) you want to do background 
> scanning; this ties in to power save mode if operating as a station. 

Opportunistic roaming is one of those things that has many knobs to 
twiddle, and depends a lot on the needs of the users. 

But we're not actually in powersave mode -- the 802.11 stack can spit
out the NULL frames to tell the AP to buffer traffic for us. This is 
trivial to do.

Scans should be specified as "non-distruptive" so the hardware driver
has to twiddle whatever bits are necessary to return the hardware to the
same state that it was in before the scan kicked in.  Beyond that, the
scanning smarts are all in the 802.11 stack.  The driver should be as
dumb as possible.  :)

Background scanning, yes -- but there are all sorts of different
thresholds and types of 'scanning' to be done, depending on how
disruptive you are willing to be, and how capable the hardware is.  Most
thin MACs don't filter out foreign BSSIDs on the same channel when
you're joined, which makes some things a lot easier.

> Further you want to order your channel list to hit the most likely 
> channels first in case you are scanning for a specific ap--e.g. so you 
> can stop the foreground scan and start to associate.  

With my scenarios, the driver performs the sweep in the order it was 
given -- if the hardware supports it, naturally.

> In terms of beacon miss processing some parts have a hardware beacon
> miss interrupt based on missed consecutive beacons but others require
> you to detect beacon miss in software.  Other times you need s/w bmiss
> detection because you're doing something like build a repeater when
> the station virtual device can't depend on the hardware to deliver a
> bmiss interrupt.

Of course.  The stack is going to need a set of timers regardless of the 
hardware's capabilities, but having (sane) hardware beacon miss 
detection capabilities makes it a bit more robust.
 
> Scanning (and roaming) is really a big can 'o worms.

Oh, I know.  I've burned out many brain cells trying to build 
supportable solutions for our customers.   

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

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

Re: wireless: recap of current issues (configuration)

[Sam Leffler]

Stuffed Crust wrote:
> On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote:
> 
>>The above is a great synopsis but there is more.  For example to support 
>>roaming (and sometimes for ap operation) you want to do background 
>>scanning; this ties in to power save mode if operating as a station. 
> 
> 
> Opportunistic roaming is one of those things that has many knobs to 
> twiddle, and depends a lot on the needs of the users. 
> 
> But we're not actually in powersave mode -- the 802.11 stack can spit
> out the NULL frames to tell the AP to buffer traffic for us. This is 
> trivial to do.

The way you implement bg scanning is to notify the ap you are going into 
power save mode before you leave the channel (in sta mode).  Hence bg 
scanning and power save operation interact.

> 
> Scans should be specified as "non-distruptive" so the hardware driver
> has to twiddle whatever bits are necessary to return the hardware to the
> same state that it was in before the scan kicked in.  Beyond that, the
> scanning smarts are all in the 802.11 stack.  The driver should be as
> dumb as possible.  :)

See above.  Doing bg scanning well is a balancing act and restoring 
hardware state is the least of your worries (hopefully); e.g. what's the 
right thing to do when you get a frame to transmit while off-channel 
scanning, how often should you return to the bss channel?

> 
> Background scanning, yes -- but there are all sorts of different
> thresholds and types of 'scanning' to be done, depending on how
> disruptive you are willing to be, and how capable the hardware is.  Most
> thin MACs don't filter out foreign BSSIDs on the same channel when
> you're joined, which makes some things a lot easier.

Er, you need to listen to at least beacons from other ap's if you're in 
11g so you can detect overlapping bss and enable protection.  There are 
other ways to handle this but that's one.

> 
> 
>>Further you want to order your channel list to hit the most likely 
>>channels first in case you are scanning for a specific ap--e.g. so you 
>>can stop the foreground scan and start to associate.  
> 
> 
> With my scenarios, the driver performs the sweep in the order it was 
> given -- if the hardware supports it, naturally.

Channel ordering is useful no matter who specifies it.  If you offload 
the ordering to the upper layers then they need to be aware of the 
regdomain constraints.  Probably not a big deal but then you need to 
synchronize info between layers or export it.  And there's other 
regdomain-related info that may want to be considered such as max 
txpower.  I'm just saying if you want to do a good job there's lots of 
work here.

> 
> 
>>In terms of beacon miss processing some parts have a hardware beacon
>>miss interrupt based on missed consecutive beacons but others require
>>you to detect beacon miss in software.  Other times you need s/w bmiss
>>detection because you're doing something like build a repeater when
>>the station virtual device can't depend on the hardware to deliver a
>>bmiss interrupt.
> 
> 
> Of course.  The stack is going to need a set of timers regardless of the 
> hardware's capabilities, but having (sane) hardware beacon miss 
> detection capabilities makes it a bit more robust.
>  
> 
>>Scanning (and roaming) is really a big can 'o worms.
> 
> 
> Oh, I know.  I've burned out many brain cells trying to build 
> supportable solutions for our customers.   

I don't recall seeing well-developed scanning code in either of the 
proposed stacks.

	Sam

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote:
> The way you implement bg scanning is to notify the ap you are going into 
> power save mode before you leave the channel (in sta mode).  Hence bg 
> scanning and power save operation interact.

That is not "powersave operation" -- that is telling the AP we are going
into powersave, but not actually going into powersave -- Actual
powersave operation would need to be disabled if we go into a scan, as
we need to have the rx path powered up and ready to hear anything out
there for the full channel dwell time.

> See above.  Doing bg scanning well is a balancing act and restoring 
> hardware state is the least of your worries (hopefully); e.g. what's the 
> right thing to do when you get a frame to transmit while off-channel 
> scanning, how often should you return to the bss channel?

Disallow all other transmits (either by failing them altogether, or by 
buffering them up, which I think is better) while performing the scan.

If we are (continually) scanning because we don't have an association, 
then we shouldn't be allowing any traffic through the stack anyway.

At the end of each scan pass, you return to the original channel, then 
return "scan complete" to the stack/userspace.  at this point any 
pending transmits can go out, and if another scan pass is desired, it 
will happen then.

> Er, you need to listen to at least beacons from other ap's if you're in 
> 11g so you can detect overlapping bss and enable protection.  There are 
> other ways to handle this but that's one.

If you can't hear the traffic, then it doesn't count for purposes of ER
protection -- but that said, this only matters for AP operation, so APs
shouldn't filter out anyone else's becacons.  STAs should respect the
"use ER Protection" bit in the AP's beacon, so can filter out traffic 
that doesn't match the configured BSSID.

> >Oh, I know.  I've burned out many brain cells trying to build 
> >supportable solutions for our customers.   
> 
> I don't recall seeing well-developed scanning code in either of the 
> proposed stacks.

I've only looked into the pre-2.6-merged HostAP stack, so I can't 
comment on what's publically available.  I'll have a look at the GPL'ed 
DeviceScape stack when I have more time.

Most of what I've going on about is derived from my experience from
commercial 802.11 work I've done over the past few years.

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

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

Re: wireless: recap of current issues (configuration)

[Sam Leffler]

Stuffed Crust wrote:
> On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote:
>> The way you implement bg scanning is to notify the ap you are going into 
>> power save mode before you leave the channel (in sta mode).  Hence bg 
>> scanning and power save operation interact.
> 
> That is not "powersave operation" -- that is telling the AP we are going
> into powersave, but not actually going into powersave -- Actual
> powersave operation would need to be disabled if we go into a scan, as
> we need to have the rx path powered up and ready to hear anything out
> there for the full channel dwell time.

Please read what I wrote again.  Station mode power save work involves 
communicating with the ap and managing the hardware.  The first 
interacts with bg scanning.  We haven't even talked about how to handle 
sta mode power save.

> 
>> See above.  Doing bg scanning well is a balancing act and restoring 
>> hardware state is the least of your worries (hopefully); e.g. what's the 
>> right thing to do when you get a frame to transmit while off-channel 
>> scanning, how often should you return to the bss channel?
> 
> Disallow all other transmits (either by failing them altogether, or by 
> buffering them up, which I think is better) while performing the scan.

Not necessarily in my experience.

> 
> If we are (continually) scanning because we don't have an association, 
> then we shouldn't be allowing any traffic through the stack anyway.

If you do not have an association you are not doing bg scanning.

> 
> At the end of each scan pass, you return to the original channel, then 
> return "scan complete" to the stack/userspace.  at this point any 
> pending transmits can go out, and if another scan pass is desired, it 
> will happen then.

If you wait until the end of the scan to return to the bss channel then 
you potentially miss buffered mcast frames.  You can up the station's 
listen interval but that only gets you so far.  As I said there are 
tradeoffs in doing this.

> 
>> Er, you need to listen to at least beacons from other ap's if you're in 
>> 11g so you can detect overlapping bss and enable protection.  There are 
>> other ways to handle this but that's one.
> 
> If you can't hear the traffic, then it doesn't count for purposes of ER
> protection -- but that said, this only matters for AP operation, so APs
> shouldn't filter out anyone else's becacons.  STAs should respect the
> "use ER Protection" bit in the AP's beacon, so can filter out traffic 
> that doesn't match the configured BSSID.

Sorry I meant this was needed for ap operation.

> 
>>> Oh, I know.  I've burned out many brain cells trying to build 
>>> supportable solutions for our customers.   
>> I don't recall seeing well-developed scanning code in either of the 
>> proposed stacks.
> 
> I've only looked into the pre-2.6-merged HostAP stack, so I can't 
> comment on what's publically available.  I'll have a look at the GPL'ed 
> DeviceScape stack when I have more time.
> 
> Most of what I've going on about is derived from my experience from
> commercial 802.11 work I've done over the past few years.

Ditto.

	Sam

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Mon, Jan 16, 2006 at 12:14:08PM -0800, Sam Leffler wrote:
> Please read what I wrote again.  Station mode power save work involves 
> communicating with the ap and managing the hardware.  The first 
> interacts with bg scanning.  We haven't even talked about how to handle 
> sta mode power save.

I think we're arguing over semantics; what's important here is that the
STA tells the AP to buffer frames while we're performing a scan,
correct?
 
> If you wait until the end of the scan to return to the bss channel then 
> you potentially miss buffered mcast frames.  You can up the station's 
> listen interval but that only gets you so far.  As I said there are 
> tradeoffs in doing this.

An excellent point.  This is particularly relevant for APs that have a
DTIM interval of 1 -- if you're doing a passive scan, the dwell time on
that other channel (you need at least one beacon interval) could cause
you to miss bufferend MCAST frames.

In all fairness I don't think I've seen any implementations that handle
this cleanly.

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

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

Re: wireless: recap of current issues (configuration)

[Dan Williams]

On Mon, 2006-01-16 at 12:28 -0500, Stuffed Crust wrote:
> Scans should be specified as "non-distruptive" so the hardware driver
> has to twiddle whatever bits are necessary to return the hardware to the
> same state that it was in before the scan kicked in.  Beyond that, the
> scanning smarts are all in the 802.11 stack.  The driver should be as
> dumb as possible.  :)

This is quite important... from a user perspective, it might be 2, 5, or
15 seconds before the card can actually scan all channels.
Unfortunately, background (passive) scanning by definition can't find
all access points, so you're going to need to do active scanning.
However, that active scanning should be controlled by userspace, not the
driver.  Only userspace knows what policies the user him/herself has set
on powersaving mode.

> Background scanning, yes -- but there are all sorts of different
> thresholds and types of 'scanning' to be done, depending on how
> disruptive you are willing to be, and how capable the hardware is.  Most
> thin MACs don't filter out foreign BSSIDs on the same channel when
> you're joined, which makes some things a lot easier.

Scanning has the tradeoff of updated network list vs. saving power +
network disruption.  The user, or programs delegated by the user, need
to make that choice, not the stack or the driver.

-------------

Furthermore, and this is also extremely important, user apps need to
know when the scan is done.  From my look at drivers, _all_ cards know
when the hardware is in scanning states, and when its done.  What many
don't do is communicate that information to userspace via wireless
events.  The userspace app that requested scanning is then stuck
busy-waiting for the SIOCGIWSCAN to return success, which just sucks.
Much better if all drivers had the wireless event so that the userspace
app could just fire off the scan with SIOCSIWSCAN, and parse the results
when the event comes back rather than spinning.

In the netlink world, this would of course be done by multicasting the
"Scan Done" message to all interested clients, which would be just as
good.

Dan

Re: wireless: recap of current issues (configuration)

[Samuel Ortiz]

On Mon, 16 Jan 2006, ext Stuffed Crust wrote:

> Background scanning, yes -- but there are all sorts of different
> thresholds and types of 'scanning' to be done, depending on how
> disruptive you are willing to be, and how capable the hardware is.  Most
> thin MACs don't filter out foreign BSSIDs on the same channel when
> you're joined, which makes some things a lot easier.
That is true, thin MACs usually don't filter beacons on the same channel.
But in some cases (mainly power saving), you really want to avoid
receiving useless beacons and having the host woken up for each of them.
You may even want to not receive all the useful ones (the ones coming from
the AP you're joined with) if your softmac allows that.
This kind of beacon filtering is a big power saver, which is one of the
most important requirement for some platforms (phones, PDA, etc...).

Cheers,
Samuel.

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Mon, Jan 16, 2006 at 09:07:52PM +0200, Samuel Ortiz wrote:
> That is true, thin MACs usually don't filter beacons on the same channel.
> But in some cases (mainly power saving), you really want to avoid
> receiving useless beacons and having the host woken up for each of them.
> You may even want to not receive all the useful ones (the ones coming from
> the AP you're joined with) if your softmac allows that.

BSSID filtering doesn't matter as far as 802.11 powersave is concerned
-- the power savings come from disabling the RF/BBP components.  In
other words, you can't receive or transmit traffic.

If you're respecting the AP's beacon interval/DTIM settings, you only 
wake up every couple of beacon intervals and listen for a beacon.  IF 
there's traffic waiting for you, then you wake up your transmitter, send 
out a PSPOLL (or NULL/PSEnd) frame, get your traffic, then go back to 
sleep again.  

You may hear another beacon when the STA is awake, you may not.  BSSID 
filtering has nothing to do with 802.11 power save, but rather is 
intented to reduce the host load (interrupts, processing overhead) and 
thus the host power consumption.

> This kind of beacon filtering is a big power saver, which is one of the
> most important requirement for some platforms (phones, PDA, etc...).

You need to be clear if you're talking about 802.11 powersave, versus 
"power savings stemming from reducing the load on the host system", 
which is where BSSID filtering is beneficial.

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

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

Re: wireless: recap of current issues (configuration)

[Samuel Ortiz]

On Mon, 16 Jan 2006, ext Stuffed Crust wrote:

> You may hear another beacon when the STA is awake, you may not.  BSSID
> filtering has nothing to do with 802.11 power save, but rather is
> intented to reduce the host load (interrupts, processing overhead) and
> thus the host power consumption.
I know that and I know a bit about 802.11 PS as well.
I was talking about host powersaving, not 802.11. Sorry for the confusion.

What I meant is that having an 802.11 stack capable of living with less
than a beacon every couple of beacon intervals would be nice as well.

Cheers,
Samuel.

Re: wireless: recap of current issues (configuration)

[Stefan Rompf]

Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:

> [Changing mode of virtual devices]
>
> IMHO there's not much point in allowing changes. I have a feeling that
> might create icky issues you don't want to have to tackle when the
> solution is easy by just not allowing it. Part of my thinking is that
> different virtual types have different structures associated, so
> changing it needs re-creating structures anyway. And different virtual
> device types might even be provided by different kernel modules so you
> don't carry around AP mode if you don't need it.

Even though it is a bit more work on kernel side, we should allow changing the 
mode of virtual devices. Let's face it, even though we find multi-BSS 
capabilities very interesting, 999 of 1000 users won't care due to the two 
facts that IPW firmware IMHO doesn't allow it and virtual interfaces are 
limited to one channel anyway. These users rightfully expect to have one 
interface and be able to do all configurations on it.

Stefan

Re: wireless: recap of current issues (configuration)

[Johannes Berg]

Stefan Rompf wrote:

> Even though it is a bit more work on kernel side, we should allow changing
> the
> mode of virtual devices. Let's face it, even though we find multi-BSS
> capabilities very interesting, 999 of 1000 users won't care due to the two
> facts that IPW firmware IMHO doesn't allow it and virtual interfaces are
> limited to one channel anyway. These users rightfully expect to have one
> interface and be able to do all configurations on it.

Isn't that rather a question of having good user-space tools that make
deactivating one type of interface and activating another seamless?

johannes

Re: wireless: recap of current issues (configuration)

[Stefan Rompf]

Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:

> Isn't that rather a question of having good user-space tools that make
> deactivating one type of interface and activating another seamless?

Well, it's always easy to point to userspace. However, unregister_netdev() 
initiates a lot of actions. IPv4 addresses and routes are removed, same for 
IPv6, IPX, Appletalk etc. Stacked VLAN devices are recursively unregistered 
(even though I have not tried yet if it works when I create VLANs over 802.3 
emulated wlan interfaces ;-), udev bloat runs. And all this stuff has to be 
restored by the nifty new configuration utility, possibly including ifindex 
and future protocols.

This is from my usage pattern that I want to go into monitor mode on current 
channel, look at some packets and return to the association without losing 
layer 3 configuration.

So after all, it is IMHO way less painful to handle a mode change in the 
kernel.

Stefan

Re: wireless: recap of current issues (configuration)

[Sam Leffler]

Stefan Rompf wrote:
> Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg:
> 
>> Isn't that rather a question of having good user-space tools that make
>> deactivating one type of interface and activating another seamless?
> 
> Well, it's always easy to point to userspace. However, unregister_netdev() 
> initiates a lot of actions. IPv4 addresses and routes are removed, same for 
> IPv6, IPX, Appletalk etc. Stacked VLAN devices are recursively unregistered 
> (even though I have not tried yet if it works when I create VLANs over 802.3 
> emulated wlan interfaces ;-), udev bloat runs. And all this stuff has to be 
> restored by the nifty new configuration utility, possibly including ifindex 
> and future protocols.
> 
> This is from my usage pattern that I want to go into monitor mode on current 
> channel, look at some packets and return to the association without losing 
> layer 3 configuration.
> 
> So after all, it is IMHO way less painful to handle a mode change in the 
> kernel.

To do what you describe I would create a monitor mode device, switch 
channel, then destroy it.  All the time you leave the station device 
unchanged, though you probably need to disable it.  This may not be 
possible with all devices--i.e. for those that require different 
firmware to do monitoring you will be restricted to a single virtual 
device and/or operating mode.

	Sam

Re: wireless: recap of current issues (configuration)

[Johannes Berg]

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

On Sun, 2006-01-15 at 12:08 -0800, Sam Leffler wrote:

> To do what you describe I would create a monitor mode device, switch 
> channel, then destroy it.  All the time you leave the station device 
> unchanged, though you probably need to disable it.  This may not be 
> possible with all devices--i.e. for those that require different 
> firmware to do monitoring you will be restricted to a single virtual 
> device and/or operating mode.

Yeah, I agree with this, it is much cleaner to handle in the kernel.
Think about the issues if you have a struct net_device that has 250
bytes of "payload" for the struct virtual_sta_device in it and you want
to switch that to a struct virtual_monitor_device. Icky.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: wireless: recap of current issues (configuration)

[Stefan Rompf]

Am Sonntag 15 Januar 2006 21:11 schrieb Johannes Berg:

> [iwconfig mode ...]
>
> Yeah, I agree with this, it is much cleaner to handle in the kernel.
> Think about the issues if you have a struct net_device that has 250
> bytes of "payload" for the struct virtual_sta_device in it and you want
> to switch that to a struct virtual_monitor_device. Icky.

Well, nobody forces you to allocate dev->priv together with the net_device, 
you can set and change this pointer yourself. So I don't see a problem here.

Stefan

Re: wireless: recap of current issues (configuration)

[Sam Leffler]

Stefan Rompf wrote:
> Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg:
> 
>> [Changing mode of virtual devices]
>>
>> IMHO there's not much point in allowing changes. I have a feeling that
>> might create icky issues you don't want to have to tackle when the
>> solution is easy by just not allowing it. Part of my thinking is that
>> different virtual types have different structures associated, so
>> changing it needs re-creating structures anyway. And different virtual
>> device types might even be provided by different kernel modules so you
>> don't carry around AP mode if you don't need it.
> 
> Even though it is a bit more work on kernel side, we should allow changing the 
> mode of virtual devices. Let's face it, even though we find multi-BSS 
> capabilities very interesting, 999 of 1000 users won't care due to the two 
> facts that IPW firmware IMHO doesn't allow it and virtual interfaces are 
> limited to one channel anyway. These users rightfully expect to have one 
> interface and be able to do all configurations on it.

My experience is that once you can create+destroy virtual devices you'll 
never want mode changing.  From a usability standpoint when you switch 
modes you typically have to reconfigure lots of settings and doing 
destroy old followed by create new is easier.  Depending on how things 
tie into hotplug you may also find things getting complicated.

Within the kernel having the operating mode of a virtual device not 
change is very good.  First it lets you isolate the rules for mix+match 
of different virtual devices at create.  Second you can partition code 
so, for example, only code required to support an ap is loaded when an 
ap mode virtual device exists.  There are other less obvious reasons 
such as firmware-based devices can load firmware based on the operating 
mode at create time but if you allow mode switching then you need to 
unload+load on the fly.  All these things can be handled with switching 
modes but the complexity is significant and the gain is minimal.

The big stumbling block I found to going with virtual devices is that it 
affects user apps.  I looked at doing things like auto-create a station 
device for backwards compatibility but decided against it.  If you 
really want this behaviour it can be done by user code.

	Sam

Re: wireless: recap of current issues (configuration)

[Mike Kershaw]

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

On Sun, Jan 15, 2006 at 11:39:41AM -0800, Sam Leffler wrote:
> The big stumbling block I found to going with virtual devices is that it 
> affects user apps.  I looked at doing things like auto-create a station 
> device for backwards compatibility but decided against it.  If you 
> really want this behaviour it can be done by user code.

Right, no reason not to just put this into a hotplug script, is there?
Is it, when it comes down to it, significantly different than automating
firmware loads for the user?

-m

-- 
Mike Kershaw/Dragorn <dragorn@kismetwireless.net>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381  A661 D7B2 8822 738B BDB1

Experts in ancient Greek culture say that people back then didn't see their
thoughts as belonging to them.  When they had a thought, it occured to them
as a god or goddess giving them an order.  Apollo was telling them to be
brave.  Athena was telling them to fall in love.
Now people hear a commercial for sour cream potato chips and rush out to buy.
	-- Chuck Palahniuk

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

Re: wireless: recap of current issues (configuration)

[Jiri Benc]

On Fri, 13 Jan 2006 23:32:02 +0100, Johannes Berg wrote:
> IMHO there's not much point in allowing changes. I have a feeling that
> might create icky issues you don't want to have to tackle when the
> solution is easy by just not allowing it. Part of my thinking is that
> different virtual types have different structures associated, so
> changing it needs re-creating structures anyway.

You are right. But it breaks compatibility with iwconfig unless we
emulate 'iwconfig mode' command by deleting and adding interface. This
means some events are generated, hotplug/udev gets involved etc.  In the
worst case it can mean that we end up with interface with a different
name.

> And different virtual
> device types might even be provided by different kernel modules so you
> don't carry around AP mode if you don't need it.

I'm not sure about your concept of softmac modules. I wrote an e-mail
some time ago explaining why I don't think it is useful and I haven't
got any reply. Please, could you answer that e-mail first? (See
http://marc.theaimsgroup.com/?l=linux-netdev&m=113404158202233&w=2)

Could you also explain how would you implement separate module for AP
mode? How would you bind that module to the rest of ieee80211,
especially in the rx path?

Thanks,

-- 
Jiri Benc
SUSE Labs

Re: wireless: recap of current issues (configuration)

[Johannes Berg]

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

On Mon, 2006-01-16 at 15:23 +0100, Jiri Benc wrote:

> You are right. But it breaks compatibility with iwconfig unless we
> emulate 'iwconfig mode' command by deleting and adding interface. This
> means some events are generated, hotplug/udev gets involved etc.  In the
> worst case it can mean that we end up with interface with a different
> name.

Eh, right. In that case, I guess that dropping compatibility here would
be the only solution. Other iwconfig could still work though. I don't
know where to draw the line.

> I'm not sure about your concept of softmac modules. I wrote an e-mail
> some time ago explaining why I don't think it is useful and I haven't
> got any reply. Please, could you answer that e-mail first? (See
> http://marc.theaimsgroup.com/?l=linux-netdev&m=113404158202233&w=2)

I didn't really participate much in that thread. Maybe softmac was a bad
example for being a module -- it just seemed to fit the current model
that the in-kernel ieee80211 module follows.

> Could you also explain how would you implement separate module for AP
> mode? How would you bind that module to the rest of ieee80211,
> especially in the rx path?

Well, if you look at p80211 that davem wrote there are functions for
handling each type of the different receive frames. These could easily
be multiplexed into function pointers the module provides.

I really don't see why a plain STA mode card should be required to carry
around all the code required for AP operation -- handling associations
of clients, powersave management wrt. buffering, ... Sure, fragmentation
is needed for all, so it needs to be in the common code, and it might
make a lot of sense to unify WDS and STA modes, but AP mode requires
fundamentally different things and a lot of code that will never be
called in STA operation.
Putting it into the same modules and then probably into the same
structures just encourages bloat and interdependencies that I don't
think should be there.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote:
> I really don't see why a plain STA mode card should be required to carry
> around all the code required for AP operation -- handling associations
> of clients, powersave management wrt. buffering, ... Sure, fragmentation

From the perspective of the hardware driver, there is little AP or 
STA-specific code, especially when IBSS is thrown in.  Thick MACs 
excepted, there's little more than "frame tx/rx, and hardware control 
twiddling".  

The AP/STA smarts happen in the 802.11 stack.  And, speaking from 
experience, it is very hard to separate them cleanly, at least not 
without incurring even more overall complexity and bloat.

It's far simpler to build them intertwined, then add a bunch of #ifdefs 
if you want to disable AP or STA mode individually to save space.

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

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

Re: wireless: recap of current issues (configuration)

[Sam Leffler]

Stuffed Crust wrote:
> On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote:
> 
>>I really don't see why a plain STA mode card should be required to carry
>>around all the code required for AP operation -- handling associations
>>of clients, powersave management wrt. buffering, ... Sure, fragmentation
> 
> 
> From the perspective of the hardware driver, there is little AP or 
> STA-specific code, especially when IBSS is thrown in.  Thick MACs 
> excepted, there's little more than "frame tx/rx, and hardware control 
> twiddling".  
> 
> The AP/STA smarts happen in the 802.11 stack.  And, speaking from 
> experience, it is very hard to separate them cleanly, at least not 
> without incurring even more overall complexity and bloat.
> 
> It's far simpler to build them intertwined, then add a bunch of #ifdefs 
> if you want to disable AP or STA mode individually to save space.

Perhaps you haven't hit some of the more recent standards that place 
more of a burden on the ap implementation?  Also some vendor-specific 
protocol features suck up space for ap mode only and it is nice to be 
able to include them only as needed.

There are several advantages to splitting up the code such as reduced 
audit complexity and real space savings but I agree that it is an open 
question whethere there's a big gain to modularizing the code by 
operating mode.

	Sam

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Mon, Jan 16, 2006 at 10:00:18AM -0800, Sam Leffler wrote:
> Perhaps you haven't hit some of the more recent standards that place 
> more of a burden on the ap implementation?  Also some vendor-specific 
> protocol features suck up space for ap mode only and it is nice to be 
> able to include them only as needed.

While there is more work to be done on the AP side, and that code may
even be easily wrapped in an #ifdef, the majority of the complexity is
shared by both the station and the AP.  It's worth mentioning that the
802.11 specs do not generally differentiate between "APs vs non-APs" --
they're all "STAs" of equal capabilities.

This is at least true of 802.11d, 802.11e, 802.11i
(supplicant/authenticator notwithstanding), 802.11j, and 802.11k.  The
general difference is that the AP needs to be aware of the state of its
associated STAs, and perform different actions depending on configured
policy and the STAs' states, whereas the STAs generally do what the AP
tells them to do.

> There are several advantages to splitting up the code such as reduced 
> audit complexity and real space savings but I agree that it is an open 
> question whethere there's a big gain to modularizing the code by 
> operating mode.

I agree that there would be some space savings, but they'd be relatively
small, at least if the stack is designed to be generic.  This would make
the most difference for tiny/embedded systems -- but they'd want to use
#ifdefs to disable all AP code entirely, which includes all of the "if 
(ap_mode) { } else { }" clauses that would litter the whole codebase, 
regardless of modularity.  (then if we use function pointers... that's a 
*lot* of virtual functions..)

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

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

Re: wireless: recap of current issues (configuration)

[Krzysztof Halasa]

"John W. Linville" <linville@tuxdriver.com> writes:

> Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon,
> raw?, other modes?) which defines its "on the air" behaviour.  Should
> this mode be fixed when the wlan device is created?

I think so. If needed one can delete and create.

>  Or something
> that can be changed when the net_device is down?

IMHO: unnecessary complicates things.

> It may be necessary to remove, suspend, and/or disable wlan devices
> in order to add, resume, and/or enable other types of wlan devices
> on the same WiPHY device (especialy true for rfmon).  A mechanism is
> needed for drivers to be able to influence or disallow combinations
> of wlan devices in accordance with capabilities of the hardware.

If the control messages go through the main (WiPHY) driver it can
decide and/or forward the request further, to the library.

Not sure about netlink. OTOH I'm at all not sure netlink should be
used for configuration. sysfs, ioctl seem a better options. Netlink
is better for state monitoring etc. I don't know it very well though.

> Do "global" config requests go to any associated wlan device?

Are they any global config settings?
sysctl or sysfs maybe?

> Or must they be directed to the WiPHY device?  Does it matter?

If you mean "settings for a particular physical card" then WiPHY.

> I think we should require "global" configuration to target the WiPHY
> device, while "local" configuration remains with the wlan device.

If "local" means "concerning the wlan device" then sure, yes.

> (I'm not sure how important this point is?)  Either way, the WiPHY
> device will need some way to be able to reject configuration requests
> that are incompatible among its associated wlan devices.  Since the
> wlan interface implementations should not be device specific, perhaps
> the 802.11 stack can be smart enough to filter-out most conflicting
> config requests before they get to the WiPHY device?

I don't think so. The hardware driver should get the request first,
the rest should look like a library.

I've played with both approaches for years and I would avoid
"802.11 using the hw driver" scenario if at all possible.
-- 
Krzysztof Halasa

Re: wireless: recap of current issues (configuration)

[Dan Williams]

On Fri, 2006-01-13 at 17:19 -0500, John W. Linville wrote:
> Configuration
> =============
> 
> Configuration seems to be coalescing around netlink.  Among other
> things, this technology provides for muliticast requests and
> asynchronous event notification.
> 
> The kernel should provide generic handlers for netlink
> configuraion messages, and there should be a per-device 80211_ops
> (wireless_ops? akin to ethtool_ops) structure for drivers to
> populate appropriately.

One other thing: capability.  It's not enough to be able to configure
the device, user-space tools also have to know what the device is
capable of before they try touching it.  Ie, which ciphers, protocols,
channels, etc.  Similar to the IWRANGE ioctl that there is now.  Half
the problem now is that you can't reliably tell what drivers support
which features, or how much they support a particular feature.  Think of
ethernet devices and whether or not they support carrier detection,
there's absolutely no way to tell that now (unless they respond to
ethtool or MII, and some cards freeze if you touch them with MII too
often).

Dan

Re: wireless: recap of current issues (configuration)

[Stuffed Crust]

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

On Sat, Jan 14, 2006 at 06:41:56PM -0500, Dan Williams wrote:
> One other thing: capability.  It's not enough to be able to configure
> the device, user-space tools also have to know what the device is
> capable of before they try touching it.  Ie, which ciphers, protocols,
> channels, etc.  Similar to the IWRANGE ioctl that there is now.  Half
> the problem now is that you can't reliably tell what drivers support
> which features, or how much they support a particular feature. 

This is an absolute requirement, especially when talking about 
encryption.  

You'd need, for example:

CAP_WEP_64
CAP_WEP_128
CAP_WEP_256 (non-standard, but often supported)
CAP_TKIP
CAP_MICHAELMIC
CAP_AES_CCMP

Then, to make things more complicated:

CAP_KEYMAPPING (can the hardware do keymapping?)
CAP_CAN_DISABLE_HWCRYPT (so if the hardware can't do TKIP, can we 
                         perform it on the host?)

And to make things even more complicated, I've seen hardware that 
supports disabling of hardware crypto, but not toggling it on the fly, 
thanks to never-fixed hardware bugs. (you have to perform a full 
reset/firmware load cycle.  this means you end up disabling host crypto 
altogether, at least if any of the networks you want to support include 
CCMP...

Other quirks -- hardware that requires host MICHAEL on transmits, but
handles it on reception, unless if the received frames are fragmented. 
Other hardware that does keymapping on rx frames, but for transmits
takes the raw keydata in the tx descriptor.  (but still requires host
MICHAEL)

The list goes on and on..

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

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

Re: wireless: recap of current issues (configuration)

[feyd]

John W. Linville wrote:
> Configuration seems to be coalescing around netlink.  Among other
> things, this technology provides for muliticast requests and
> asynchronous event notification.

On the other hand, the tree structure of sysfs can handle the
resource exclusivity and sharing naturaly.

A proposal of the layout:

template - template of device that can be created
profile  - exclusive set of templates and other resources

plain SoftMAC card:
/sys/class/ieee80211/phy0/profile0/template0/mode      # ap
                      |      |              /...       # ap specific stuff
                      |      |
                      |      *--->/template1/mode      # sta
                      |      |              /...       # sta specific stuff
                      |      |
                      |      *--->/template2/mode      # rfmon
                      |                     /...       # rfmon specific stuff
                      |
                      *->/profile
                         /channel
                         /txpower
                         /...                   # other phy specific stuff


FullMAC card with mode constraints:
/sys/class/ieee80211/phy0/profile0/template0/mode      # sta
                      |                     /...       # sta specific stuff
                      |
                      *->/profile1/template0/mode      # rfmon
                      |                     /...       # rfmon specific stuff
                      |
                      *->/...                   # phy specific stuff


virtual interface:
/sys/class/ieee80211/sta0/parent      # ->../phy0
                         /...


card with two chips that share some phy resources:
/sys/class/ieee80211/phy0/txpower     # shared txpower
                         /...

/sys/class/ieee80211/phy1/parent      # ->../phy0
                         /channel     # independent
                         /...

/sys/class/ieee80211/phy2/parent      # ->../phy0
                         /channel     # independent
                         /...

Feyd

wireless: recap of current issues (compatibility)

[John W. Linville]

Compatibility
=============

The netlink configuration mechanism needs compatibility code to
translate wireless extension ioctls into netlink transactions.

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).

We need an ethernet<->802.11 translational bridging interface for
compatibility, and to enable 802.1 bridging with ethernet.  This could
be a configuration setting for a wlan interface.  It might be limited
to wlan interfaces in station (or WDS) mode?

802.11 framing may break older protocols (e.g. DECnet).  I don't
see this as a big problem, as I imagine such installations aren't
rolling-out lots of WiFi...if I'm wrong, will the translational
bridging code resolve this issue?

Should a default wlan device be created at WiPHY init?  Should it
enable translational bridging?  I'm inclined against this, but is it
worthwhile for compatibility?  Could/should this be a configuration
option for the stack?

How about if WiPHY initialization triggered a netlink broadcast?
Then a daemon could monitor those broadcasts and create whatever wlan
devices (ethernet emulation, rfmon, none at all) that the daemon was
configured to create.  How would this effect modprobe behaviour?
-- 
John W. Linville
linville@tuxdriver.com

Re: wireless: recap of current issues (compatibility)

[Johannes Berg]

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


> The netlink configuration mechanism needs compatibility code to
> translate wireless extension ioctls into netlink transactions.

I think we could restrict this to allow ioctl configuration only if
there's just a single active virtual dev [excluding some special cases
like changing the mode which would (see above) require deactivating one
and activating another virtual dev. or is that not possible without
screwing up naming etc? that might get tricky if we disallow mode
changing, but can probably be worked around easier than allowing mode
changing, especially since this is to be deprecated]

> Should a default wlan device be created at WiPHY init?  Should it
> enable translational bridging?  I'm inclined against this, but is it
> worthwhile for compatibility?  Could/should this be a configuration
> option for the stack?

If you want the old userspace API to 'just work' you have to create one
default wlan device at WiPHY init.

> How about if WiPHY initialization triggered a netlink broadcast?

It definitely should, in any case.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: wireless: recap of current issues (compatibility)

[Krzysztof Halasa]

Johannes Berg <johannes@sipsolutions.net> writes:

> If you want the old userspace API to 'just work' you have to create one
> default wlan device at WiPHY init.

I'm not sure the old API is that important. This isn't something
programs (third party, kernel utils don't count) rely on. Most users
would switch to the new stack immediately anyway.

It could probably be a separate compatibility module, the core stack
probably don't have to know about it. The last to worry about I'd say.
-- 
Krzysztof Halasa

wireless: recap of current issues (other issues)

[John W. Linville]

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

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

[Johannes Berg]

[-- 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 --]

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

[Johannes Berg]

[-- 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 --]

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

[Jeff Garzik]

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

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

[John W. Linville]

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

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

[David S. Miller]

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.

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

[Arnaldo Carvalho de Melo]

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

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

[Stuffed Crust]

[-- 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 --]

Re: wireless: recap of current issues (other issues / fake ethernet)

[Stefan Rompf]

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

Re: wireless: recap of current issues (other issues / fake ethernet)

[Stuffed Crust]

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

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.

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

wireless: recap of current issues (actions)

[John W. Linville]

Actions
=======

I need to establish a public git tree for wireless.  I would like for
this to be on kernel.org, but I haven't got an account established
there yet.  I've been dragging my feet a little, hoping that the
kernel.org account would materialize.

I intend to get the sipsolutions softmac code into the wireless
development kernels ASAP.  I hope this will spur driver writers that
need this functionality to start consolidating on the in-kernel stack.

Obviously, what to do with the DeviceScape stack is a pressing issue.
I am open to taking patches to introduce the DeviceScape stack on a
branch under the (still coming) wireless tree.  Obviously, patches
that bring features from the DeviceScape stack to the ieee80211 stack
would be generally welcome.

Since we are toying with the issue of multiple stacks (at least in the
wireless development kernels), some thought needs to be done w.r.t. how
to make a final decision between the two stacks.  An objective lists
of functional feature requirements seems like a good place to start.
IOW, I would like to have a list of features that would trigger the
removal of one stack shortly after the other stack achieves support
for the list.  Is this feasible?
-- 
John W. Linville
linville@tuxdriver.com

Re: wireless: recap of current issues (actions)

[Johannes Berg]

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

On Fri, 2006-01-13 at 17:25 -0500, John W. Linville wrote:

> Since we are toying with the issue of multiple stacks (at least in the
> wireless development kernels), some thought needs to be done w.r.t. how
> to make a final decision between the two stacks.  An objective lists
> of functional feature requirements seems like a good place to start.
> IOW, I would like to have a list of features that would trigger the
> removal of one stack shortly after the other stack achieves support
> for the list.  Is this feasible?

I started collecting some info on
http://johannes.sipsolutions.net/802.11_stacks
That page should probably be moved somewhere (netdev wiki?) where it is
writable by others. I also need to update it to include comments by Jean
Tourrilhes.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: wireless: recap of current issues (actions)

[Jeff Garzik]

John W. Linville wrote:
> Actions
> =======
> 
> I need to establish a public git tree for wireless.  I would like for
> this to be on kernel.org, but I haven't got an account established
> there yet.  I've been dragging my feet a little, hoping that the
> kernel.org account would materialize.

> Since we are toying with the issue of multiple stacks (at least in the
> wireless development kernels), some thought needs to be done w.r.t. how
> to make a final decision between the two stacks.  An objective lists
> of functional feature requirements seems like a good place to start.
> IOW, I would like to have a list of features that would trigger the
> removal of one stack shortly after the other stack achieves support
> for the list.  Is this feasible?

Also, an objective and honest list of problems with both stacks should 
be considered...

	Jeff

Re: wireless: recap of current issues (actions)

[John W. Linville]

On Sat, Jan 14, 2006 at 05:11:27PM -0500, Jeff Garzik wrote:
> John W. Linville wrote:

> >Since we are toying with the issue of multiple stacks (at least in the
> >wireless development kernels), some thought needs to be done w.r.t. how
> >to make a final decision between the two stacks.  An objective lists
> >of functional feature requirements seems like a good place to start.
> >IOW, I would like to have a list of features that would trigger the
> >removal of one stack shortly after the other stack achieves support
> >for the list.  Is this feasible?
> 
> Also, an objective and honest list of problems with both stacks should 
> be considered...

Yes, someone (Johannes?  Jiri?) had the beginnings of this a few days
ago, but I seem to have lost the link.  Could someone repost it?

John
-- 
John W. Linville
linville@tuxdriver.com

Re: wireless: recap of current issues (actions)

[Johannes Berg]

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

On Sat, 2006-01-14 at 19:56 -0500, John W. Linville wrote:

> Yes, someone (Johannes?  Jiri?) had the beginnings of this a few days
> ago, but I seem to have lost the link.  Could someone repost it?

http://johannes.sipsolutions.net/802.11_stacks/

Someone should start a new page to collect all the info we're talking
about at the moment on the netdev wiki and then also move this content
there. I don't think I'll get to it in the next few days.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

wireless: recap of current issues (stack)

[John W. Linville]

Stack
=====

Is the in-kernel stack up-to-date w/ SourceForge?  No.  Why not?
Can this development be brought into wireless development kernels?

Can the in-kernel stack be saved?  With the addition of softmac?
Is it possible to extend softmac to support virtual wlan devices?
If not, how do we proceed?

How do we get more drivers in-kernel?  (Multiple stacks probably
don't help beyond the short-term timeframe.)

I think we need to rally as many driver writers as possible a) to
get into the kernel now; and, b) move away from duplicating stack
features.  I don't see how to achieve that with the DeviceScape stack
in the short- or medium-term timeframe.  I get the impression that
porting drivers from one stack to the other is not all that painful,
particularly in the ieee80211->DeviceScape direction.  Is it reasonable
to expect short-term development to stay with the ieee80211 stack,
while planning either a migration to DeviceScape or a major ieee80211
overhaul based on the DeviceScape code?

Do we need to have both wireless-stable and wireless-devel kernels?
What about the suggestion of having both stacks in the kernel at once?
I'm not very excited about two in-kernel stacks.  Still, consolidating
wireless drivers down to two stacks is probably better than what we
have now...?  Either way, we would have to have general understanding
that at some point (not too far away), one of the stacks would have
to disappear.
-- 
John W. Linville
linville@tuxdriver.com

Re: wireless: recap of current issues (stack)

[Johannes Berg]

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

On Fri, 2006-01-13 at 17:22 -0500, John W. Linville wrote:

> Can the in-kernel stack be saved?  With the addition of softmac?
> Is it possible to extend softmac to support virtual wlan devices?
> If not, how do we proceed?

Well, softmac doesn't really have too many issues [that make it
incompatible with the planned stuff, that is]. Right now it layers
above ieee80211_device, and it would continue doing so, with
ieee80211_device transformed into the representation of the virtual STA
device.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: wireless: recap of current issues (stack)

[Chase Venters]

On Friday 13 January 2006 15:32, John W. Linville wrote:
> Do we need to have both wireless-stable and wireless-devel kernels?
> What about the suggestion of having both stacks in the kernel at once?
> I'm not very excited about two in-kernel stacks.  Still, consolidating
> wireless drivers down to two stacks is probably better than what we
> have now...?  Either way, we would have to have general understanding
> that at some point (not too far away), one of the stacks would have
> to disappear.

Having not had experience coding for the stacks, I'm not inclined to form an 
opinion on which is better. I think on a realistic footing, a stack switch 
should only occur if it doesn't come at great expense (unless that great 
expense is less than the expense of making the existing stack capable enough 
to handle all the devices we want to support).

But I have to NAK the idea of two stacks. There are implications in the 'here 
and now', so to speak, but what worries me the most is long term. You know 
how it's no fun fixing bugs when you could be adding new features? Let's say 
that on May 2006, you drop the hammer and decide that Stack B is the winner. 
You've now got to convince / motivate the Stack A users to stop what they're 
doing and work hard to migrate to Stack B. There might be stragglers, so 
let's say you set a "drop dead date". Now what happens if we reach that date 
and some drivers still aren't ready. "Tough," you say, "you've had ample 
notice and time to port." Now we've got a flamewar on our hands, because no 
one wants to release a new kernel that drops support for things people are 
using.

By contrast, if we got softmac in, ieee80211 may still be lacking in some 
areas, but if we do the hard work to port a few drivers and get them in-tree 
and working well, you start to have happy users. Motivation will build for 
others to port and get into the tree (partly because no one wants to be the 
odd man out, and their users will probably be frustrated by it too), and part 
of the motivation should extend naturally onto improving in-kernel ieee80211 
enough to support whatever odd-ball implementations they're dealing with. So 
I think you end up with a nice snowball effect.

As an aside to this whole thing, I know we're talking about *kernel* wireless 
but it's worthless to most people without good userland support as well. 
Anyone have any thoughts and feelings on what things look like on the 
desktop? I think if we work closely with some desktop people, we can shepard 
in some wonderful new desktop support on top of the new netlink API.

Cheers,
Chase Venters

Re: wireless: recap of current issues (stack)

[Chase Venters]

On Friday 13 January 2006 15:32, John W. Linville wrote:
> Do we need to have both wireless-stable and wireless-devel kernels?
> What about the suggestion of having both stacks in the kernel at once?
> I'm not very excited about two in-kernel stacks.  Still, consolidating
> wireless drivers down to two stacks is probably better than what we
> have now...?  Either way, we would have to have general understanding
> that at some point (not too far away), one of the stacks would have
> to disappear.

Having not had experience coding for the stacks, I'm not inclined to form an 
opinion on which is better. I think on a realistic footing, a stack switch 
should only occur if it doesn't come at great expense (unless that great 
expense is less than the expense of making the existing stack capable enough 
to handle all the devices we want to support).

But I have to NAK the idea of two stacks. There are implications in the 'here 
and now', so to speak, but what worries me the most is long term. You know 
how it's no fun fixing bugs when you could be adding new features? Let's say 
that on May 2006, you drop the hammer and decide that Stack B is the winner. 
You've now got to convince / motivate the Stack A users to stop what they're 
doing and work hard to migrate to Stack B. There might be stragglers, so 
let's say you set a "drop dead date". Now what happens if we reach that date 
and some drivers still aren't ready. "Tough," you say, "you've had ample 
notice and time to port." Now we've got a flamewar on our hands, because no 
one wants to release a new kernel that drops support for things people are 
using.

By contrast, if we got softmac in, ieee80211 may still be lacking in some 
areas, but if we do the hard work to port a few drivers and get them in-tree 
and working well, you start to have happy users. Motivation will build for 
others to port and get into the tree (partly because no one wants to be the 
odd man out, and their users will probably be frustrated by it too), and part 
of the motivation should extend naturally onto improving in-kernel ieee80211 
enough to support whatever odd-ball implementations they're dealing with. So 
I think you end up with a nice snowball effect.

As an aside to this whole thing, I know we're talking about *kernel* wireless 
but it's worthless to most people without good userland support as well. 
Anyone have any thoughts and feelings on what things look like on the 
desktop? I think if we work closely with some desktop people, we can shepard 
in some wonderful new desktop support on top of the new netlink API.

Cheers,
Chase Venters

Re: wireless: recap of current issues (stack)

[Simon Kelley]

Chase Venters wrote:

> As an aside to this whole thing, I know we're talking about *kernel* wireless 
> but it's worthless to most people without good userland support as well. 
> Anyone have any thoughts and feelings on what things look like on the 
> desktop? I think if we work closely with some desktop people, we can shepard 
> in some wonderful new desktop support on top of the new netlink API.
> 

An obvious place to start is the NetworkManager project. They should be 
asked the obvious "what do you need" and "does this provide it" 
questions. Dan Williams has been active recently producing small kernel 
patches which make the kernel side stuff work better with NM, so he 
might be a good contact to start with.

Cheers,

Simon.

Re: wireless: recap of current issues (stack)

[Simon Kelley]

Chase Venters wrote:

> As an aside to this whole thing, I know we're talking about *kernel* wireless 
> but it's worthless to most people without good userland support as well. 
> Anyone have any thoughts and feelings on what things look like on the 
> desktop? I think if we work closely with some desktop people, we can shepard 
> in some wonderful new desktop support on top of the new netlink API.
> 

An obvious place to start is the NetworkManager project. They should be 
asked the obvious "what do you need" and "does this provide it" 
questions. Dan Williams has been active recently producing small kernel 
patches which make the kernel side stuff work better with NM, so he 
might be a good contact to start with.

Cheers,

Simon.

Re: wireless: recap of current issues (stack)

[Dan Williams]

On Sat, 2006-01-14 at 10:46 +0000, Simon Kelley wrote:
> Chase Venters wrote:
> 
> > As an aside to this whole thing, I know we're talking about *kernel* wireless 
> > but it's worthless to most people without good userland support as well. 
> > Anyone have any thoughts and feelings on what things look like on the 
> > desktop? I think if we work closely with some desktop people, we can shepard 
> > in some wonderful new desktop support on top of the new netlink API.
> > 
> 
> An obvious place to start is the NetworkManager project. They should be 
> asked the obvious "what do you need" and "does this provide it" 
> questions. Dan Williams has been active recently producing small kernel 
> patches which make the kernel side stuff work better with NM, so he 
> might be a good contact to start with.

We are actually moving NM on top of wpa_supplicant for the actual
connection process.  So essentially, while NM does talk to the card for
information and scanning, wpa_supplicant provides the bulk of the actual
connection process control.  Any card that works with wpa_supplicant
should then work with NetworkManager.

Novel's is working on a KDE applet for NM which should hit CVS soon, I
think.

Dan

Re: wireless: recap of current issues (stack)

[Dan Williams]

On Sat, 2006-01-14 at 10:46 +0000, Simon Kelley wrote:
> Chase Venters wrote:
> 
> > As an aside to this whole thing, I know we're talking about *kernel* wireless 
> > but it's worthless to most people without good userland support as well. 
> > Anyone have any thoughts and feelings on what things look like on the 
> > desktop? I think if we work closely with some desktop people, we can shepard 
> > in some wonderful new desktop support on top of the new netlink API.
> > 
> 
> An obvious place to start is the NetworkManager project. They should be 
> asked the obvious "what do you need" and "does this provide it" 
> questions. Dan Williams has been active recently producing small kernel 
> patches which make the kernel side stuff work better with NM, so he 
> might be a good contact to start with.

We are actually moving NM on top of wpa_supplicant for the actual
connection process.  So essentially, while NM does talk to the card for
information and scanning, wpa_supplicant provides the bulk of the actual
connection process control.  Any card that works with wpa_supplicant
should then work with NetworkManager.

Novel's is working on a KDE applet for NM which should hit CVS soon, I
think.

Dan

Re: wireless: recap of current issues (stack)

[Michael Buesch]

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

On Saturday 14 January 2006 00:03, you wrote:
> As an aside to this whole thing, I know we're talking about *kernel* wireless 
> but it's worthless to most people without good userland support as well. 
> Anyone have any thoughts and feelings on what things look like on the 
> desktop? I think if we work closely with some desktop people, we can shepard 
> in some wonderful new desktop support on top of the new netlink API.

I am in the KDE development and have (almost) full access to the KDE svn
repository. Altought I did not do much coding on KDE apps recently,
I will be able to help in WiFi support for KDE.
The first thing I thought of, was a tray icon with basic information
about the available interfaces and basic configuration
capabilities.

-- 
Greetings Michael.

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

Re: wireless: recap of current issues (stack)

[Michael Buesch]

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

On Saturday 14 January 2006 00:03, you wrote:
> As an aside to this whole thing, I know we're talking about *kernel* wireless 
> but it's worthless to most people without good userland support as well. 
> Anyone have any thoughts and feelings on what things look like on the 
> desktop? I think if we work closely with some desktop people, we can shepard 
> in some wonderful new desktop support on top of the new netlink API.

I am in the KDE development and have (almost) full access to the KDE svn
repository. Altought I did not do much coding on KDE apps recently,
I will be able to help in WiFi support for KDE.
The first thing I thought of, was a tray icon with basic information
about the available interfaces and basic configuration
capabilities.

-- 
Greetings Michael.

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

Re: wireless: recap of current issues (stack)

[Jean Tourrilhes]

On Sat, Jan 14, 2006 at 02:51:14PM +0100, Michael Buesch wrote:
> On Saturday 14 January 2006 00:03, you wrote:
> > As an aside to this whole thing, I know we're talking about *kernel* wireless 
> > but it's worthless to most people without good userland support as well. 
> > Anyone have any thoughts and feelings on what things look like on the 
> > desktop? I think if we work closely with some desktop people, we can shepard 
> > in some wonderful new desktop support on top of the new netlink API.
> 
> I am in the KDE development and have (almost) full access to the KDE svn
> repository. Altought I did not do much coding on KDE apps recently,
> I will be able to help in WiFi support for KDE.
> The first thing I thought of, was a tray icon with basic information
> about the available interfaces and basic configuration
> capabilities.

	There is already at least 2 KDE applications for WiFi stuff,
and both are fully fledged (i.e. not just a signal meter) :
		http://websvn.kde.org/trunk/KDE/kdenetwork/wifi/
		http://websvn.kde.org/trunk/kdenonbeta/kifi/
	Note that I've used neither, so I don't know how good they are
and what features are missing. If you decide to write another apps,
please send me the link so I can add it on my web page.

> Greetings Michael.

	Have fun...

	Jean

Re: wireless: recap of current issues (stack)

[Jean Tourrilhes]

On Sat, Jan 14, 2006 at 02:51:14PM +0100, Michael Buesch wrote:
> On Saturday 14 January 2006 00:03, you wrote:
> > As an aside to this whole thing, I know we're talking about *kernel* wireless 
> > but it's worthless to most people without good userland support as well. 
> > Anyone have any thoughts and feelings on what things look like on the 
> > desktop? I think if we work closely with some desktop people, we can shepard 
> > in some wonderful new desktop support on top of the new netlink API.
> 
> I am in the KDE development and have (almost) full access to the KDE svn
> repository. Altought I did not do much coding on KDE apps recently,
> I will be able to help in WiFi support for KDE.
> The first thing I thought of, was a tray icon with basic information
> about the available interfaces and basic configuration
> capabilities.

	There is already at least 2 KDE applications for WiFi stuff,
and both are fully fledged (i.e. not just a signal meter) :
		http://websvn.kde.org/trunk/KDE/kdenetwork/wifi/
		http://websvn.kde.org/trunk/kdenonbeta/kifi/
	Note that I've used neither, so I don't know how good they are
and what features are missing. If you decide to write another apps,
please send me the link so I can add it on my web page.

> Greetings Michael.

	Have fun...

	Jean

Re: wireless: recap of current issues (stack)

[Ulrich Kunitz]

On Fri, 13 Jan 2006, John W. Linville wrote:

> Can the in-kernel stack be saved?  With the addition of softmac?
> Is it possible to extend softmac to support virtual wlan devices?
> If not, how do we proceed?

I don't think, that we can continue with the current model of the
stacks. There appears a great variance in the HOST-device
interfaces between WLAN devices of several vendors. The other
problem is, that there is a difference depending on the bus the
device is connected to. Register accesses in USB devices should be
able to sleep. However the 80211 stacks I've seen so far have a
fixed set of capabilities and do also assume, that at the driver
layer everything can be done in atomic mode, which is only true
for buses that support memory-mapping.

In my point of view each stack layer must allow drivers to
overwrite all entry-functions. Drivers could then do
cherry-picking of the provided standard-functions. This is of
course the library approach. The discussion about multiple
stacks will then be muted, because we would have several stacks in
the kernel and on the devices, which would have compatible interfaces.

> Do we need to have both wireless-stable and wireless-devel kernels?
> What about the suggestion of having both stacks in the kernel at once?
> I'm not very excited about two in-kernel stacks.  Still, consolidating
> wireless drivers down to two stacks is probably better than what we
> have now...?  Either way, we would have to have general understanding
> that at some point (not too far away), one of the stacks would have
> to disappear.

See above.

-- 
Ulrich Kunitz - kune@deine-taler.de

Re: wireless: recap of current issues (stack)

[Pete Zaitcev]

On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <kune@deine-taler.de> wrote:

> [...] Register accesses in USB devices should be
> able to sleep. However the 80211 stacks I've seen so far have a
> fixed set of capabilities and do also assume, that at the driver
> layer everything can be done in atomic mode, which is only true
> for buses that support memory-mapping.

If this problem is real, then it's serious. However, I'm not seeing it
with prism54usb and Berg's softmac (yet?). Would you be so kind to provide
the file name and function name for the code which makes these assumptions?

Thanks,
-- Pete

Re: wireless: recap of current issues (stack)

[Ulrich Kunitz]

On Sat, 14 Jan 2006, Pete Zaitcev wrote:

> On Sat, 14 Jan 2006 15:13:39 +0100 (CET), Ulrich Kunitz <kune@deine-taler.de> wrote:
> 
> > [...] Register accesses in USB devices should be
> > able to sleep. However the 80211 stacks I've seen so far have a
> > fixed set of capabilities and do also assume, that at the driver
> > layer everything can be done in atomic mode, which is only true
> > for buses that support memory-mapping.
> 
> If this problem is real, then it's serious. However, I'm not seeing it
> with prism54usb and Berg's softmac (yet?). Would you be so kind to provide
> the file name and function name for the code which makes these assumptions?
> 
> Thanks,
> -- Pete
> 

Pete,

I've been wrong.

I couldn't find the problem in the latest version of the
ieee80211softmac. Thank you for noticing me.

Uli

-- 
Ulrich Kunitz - kune@deine-taler.de

Re: wireless: recap of current issues

[Ben Greear]

This is a re-send since the lists ate my reply.  I've also
trimmed out all but netdev and lkml email addresses.

 > Do "global" config requests go to any associated wlan device?
 > Or must they be directed to the WiPHY device?  Does it matter?
 > I think we should require "global" configuration to target the WiPHY
 > device, while "local" configuration remains with the wlan device.
 > (I'm not sure how important this point is?)  Either way, the WiPHY
 > device will need some way to be able to reject configuration requests
 > that are incompatible among its associated wlan devices.  Since the
 > wlan interface implementations should not be device specific, perhaps
 > the 802.11 stack can be smart enough to filter-out most conflicting
 > config requests before they get to the WiPHY device?


I'd create a generic function that handles most things, but allow the
driver to over-ride this method if it knows better.  Something like
is_ok_to_add(new wlan device info);
might need an is_ok_to_remove(foo); as well.

 > We need an ethernet<->802.11 translational bridging interface for
 > compatibility, and to enable 802.1 bridging with ethernet.  This could
 > be a configuration setting for a wlan interface.  It might be limited
 > to wlan interfaces in station (or WDS) mode?


If we can send a raw ethernet frame at the driver/stack, then it can
reject or send as needed.  For instance, you should be able to 'bridge'
to a regular station interface _IF_ the source MAC matches the station's
source MAC.  This would also allow the packet-socket code to work with
wifi just like it does with wired ethernet (and 802.1Q VLANs, for that matter.)

 > Should a default wlan device be created at WiPHY init?  Should it
 > enable translational bridging?  I'm inclined against this, but is it
 > worthwhile for compatibility?  Could/should this be a configuration
 > option for the stack?


I wouldn't...can't see how it helps anything.

 > Stack
 > =====
 >
 > Is the in-kernel stack up-to-date w/ SourceForge?  No.  Why not?
 > Can this development be brought into wireless development kernels?
 >
 > Can the in-kernel stack be saved?  With the addition of softmac?
 > Is it possible to extend softmac to support virtual wlan devices?
 > If not, how do we proceed?
 >
 > How do we get more drivers in-kernel?  (Multiple stacks probably
 > don't help beyond the short-term timeframe.)


One thing multiple in-kernel stacks might give us would be an easier way for
developers (especially those not fully versed in wifi)
to try out features of both stacks and make merging between
the stacks easier (with the goal of having only one stack).  It would probably
allow more drivers to get in immediately as well, which should get
more developers working on the same core logic.

 > 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?)


With regard to conflicting virtual devices:  How about treat all 'DOWN'
devices as irrelevent to the physical device.  That way, you can have
rfmon, AP, station, etc devices all configured at once, and just ifdown/ifup
the one(s) you want to use at any given point.  The virtual interfaces can
keep all config info needed to bring themselves back online.

 > 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...


Ignore for now..maybe it will get more active maintenance when the
stack solidifies enough to make developing wifi less complex.


 > Since we are toying with the issue of multiple stacks (at least in the
 > wireless development kernels), some thought needs to be done w.r.t. how
 > to make a final decision between the two stacks.  An objective lists
 > of functional feature requirements seems like a good place to start.
 > IOW, I would like to have a list of features that would trigger the
 > removal of one stack shortly after the other stack achieves support
 > for the list.  Is this feasible?


Would it be possible to write a very thin 'shim' stack that could
sit over either device-scape or the current stack?  This shim could
start solidifying the API with user-space somewhat independently of
the lower levels.  If one stack did not support a particular feature,
then it just returns a failure code.  If this is not too much work,
it might allow the stack merge to happen gradually.  Of course, this
might be more work than it's worth...

Thanks for all the work you're doing!

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com