proposal for new wireless configuration API

proposal for new wireless configuration API

[Johannes Berg]

Hi,

So I've thought about this all day long... After writing this mail I'll
go home and hope my inbox collects some feedback ;)

I've arrived at the following conclusions:
 * we want to use genetlink
 * we need an equivalent of the old commit() call,
   but without all the stupidity
 * we want to do packet injection and many other advanced
   features with it, and keep it extensible

NB: I have some code, so don't start ;)

Hence, I came up with the following system. Note that I don't use any
private header for the netlink messages.

 - we implement a bunch of commands, for example NL80211_CMD_INJECT and
   _SETATTR, _GETATTR[(attrnumber)] [easy with dumpit()],
   _GETATTRGROUP, ...

 - we have a whole bunch of possible attributes:
   NL80211_ATTR_FLAGS: flags for injecting a packet (e.g. want_notify)
   NL80211_ATTR_IFINDEX: index of interface to use
   (NL80211_ATTR_PHYIDX: (later) index of wiphy to configure)
   NL80211_ATTR_ESSID,
                FRAGTHRESHOLD,
                CHANNEL,...: most of the old wext ioctls map to
                             attributes now
   NL80211_ATTR_FRAME: frame to inject, or received mgmt frame

 - we use a few multicast groups:
    (a) one for management frames that are received
    (b) one for scan results as they come available
        (When, for example, someone requests scan results, they are
         simply multicast to the group+the requester, if they come
         available during operation they can also be multicast here)

Note that I haven't mentioned commit(). NL80211_CMD_GETATTRGROUP returns
a list of attributes that make sense to set with a single _SETATTR call
and multiple attributes.

an old sequence of
  iwconfig eth0 essid 'lalala'
  iwconfig eth0 channel 2
  iwconfig eth0 commit
would then be translated in the compat layer to a single _SETATTR
message with the channel and essid attributes. Ultimately, we'll get rid
of this, so a userspace tool using the netlink configuration would just
tell the user via _GETATTRGROUP which attributes make sense to group
together for optimal card behaviour.

As for the inject command, it looks like on the current wmgmt# interface
for d80211 has a bunch of implicit behaviour like looking into the
transmitted frame to see what type it is etc. I'd like to get rid of it
and stuff the information for that into ATTR_FLAGS instead.

Oh and of course we'll have a structure somewhere that drivers and
stacks register with the module that provides this netlink interface.
That module will then also multiplex the commands to the drivers/stacks.
I have that mostly figured out.

Since it will be easy to tell if a specific driver/stack implements
old-style wext or this new API we can allow drivers with both APIs to
coexist for a while. I won't map the new API to the old wext one of
course, but mapping the wext API to the new one we need anyway. Hence,
we can change the wext code to call the new API if present and the old
one otherwise (with a big fat printk), and then slowly migrate drivers
over. Due to the reduced commit logic, it should become simpler too,
even for old drivers.

Anyway, comments appreciated. If we can agree on this general framework
I'll start implementing the groundwork and some of the rest for d80211
soon.

johannes

Re: proposal for new wireless configuration API

[Luis R. Rodriguez]

This all sounds good to me. A few comments here, to give you something
to read when you get home.

On 8/15/06, Johannes Berg <johannes@sipsolutions.net> wrote:

>  - we implement a bunch of commands, for example NL80211_CMD_INJECT and
>    _SETATTR, _GETATTR[(attrnumber)] [easy with dumpit()],
>    _GETATTRGROUP, ...

Basically redo WE completely from scratch using netlink.

>  - we have a whole bunch of possible attributes:
>    NL80211_ATTR_FLAGS: flags for injecting a packet (e.g. want_notify)

For per packet this makes sense, for modification of all packets I
think configfs would be more suitable. Then again this is just an
addition, I'm not disagreeing here with the approach. The same goes
for several common wireless settings -- we could also have a configfs
directory for each device which would allow manual read/writing for
setting/getting certain values; mind you that congifs does allow for
setting/getting multiple values at the same time, for those of you who
have wondered. This could just could easily go in as a wrapper for
configfs->new NL API.

>    NL80211_ATTR_IFINDEX: index of interface to use
>    (NL80211_ATTR_PHYIDX: (later) index of wiphy to configure)

Do you mean to have a wireless device have its own device index,
separate from the netdevice index? Can you elaborate a bit on this?

>    NL80211_ATTR_ESSID,
>                 FRAGTHRESHOLD,
>                 CHANNEL,...: most of the old wext ioctls map to
>                              attributes now

With WE we were restricted to the number of attributes possibly
changed by the number of ioctls and later by sub-ioctl hack
restrictions. What restrictions are we to face with this? Do we want
to map each attribute directly to the respective WE ioctl number to
make it easy to do backward compatibility?

  Luis

Re: proposal for new wireless configuration API

[Dan Williams]

On Tue, 2006-08-15 at 17:28 +0200, Johannes Berg wrote:
> Hi,
> 
> So I've thought about this all day long... After writing this mail I'll
> go home and hope my inbox collects some feedback ;)

We might want to take the time to fix up a few of the ambiguities of
WEXT that we've encountered over the past few years:

o Separate attributes for signal strength units; signed integer type for
dBm, unsigned integer type for RSSI.  One 8-bit var to represent both is
just too confusing for people, evidently (which is true...)

o Merge functionality ENCODE and ENCODEEXT handlers into one

o Separate attributes for channel and frequency

o Method of finding out channel <-> frequency mapping (not all drivers
support this in the SIOCGIWRANGE handler now)

Nothing big here...  but gives driver writers a much easier target to
hit, and userspace app writers an easier API to understand.

Dan

> I've arrived at the following conclusions:
>  * we want to use genetlink
>  * we need an equivalent of the old commit() call,
>    but without all the stupidity
>  * we want to do packet injection and many other advanced
>    features with it, and keep it extensible
> 
> NB: I have some code, so don't start ;)
> 
> Hence, I came up with the following system. Note that I don't use any
> private header for the netlink messages.
> 
>  - we implement a bunch of commands, for example NL80211_CMD_INJECT and
>    _SETATTR, _GETATTR[(attrnumber)] [easy with dumpit()],
>    _GETATTRGROUP, ...
> 
>  - we have a whole bunch of possible attributes:
>    NL80211_ATTR_FLAGS: flags for injecting a packet (e.g. want_notify)
>    NL80211_ATTR_IFINDEX: index of interface to use
>    (NL80211_ATTR_PHYIDX: (later) index of wiphy to configure)
>    NL80211_ATTR_ESSID,
>                 FRAGTHRESHOLD,
>                 CHANNEL,...: most of the old wext ioctls map to
>                              attributes now
>    NL80211_ATTR_FRAME: frame to inject, or received mgmt frame
> 
>  - we use a few multicast groups:
>     (a) one for management frames that are received
>     (b) one for scan results as they come available
>         (When, for example, someone requests scan results, they are
>          simply multicast to the group+the requester, if they come
>          available during operation they can also be multicast here)
> 
> Note that I haven't mentioned commit(). NL80211_CMD_GETATTRGROUP returns
> a list of attributes that make sense to set with a single _SETATTR call
> and multiple attributes.
> 
> an old sequence of
>   iwconfig eth0 essid 'lalala'
>   iwconfig eth0 channel 2
>   iwconfig eth0 commit
> would then be translated in the compat layer to a single _SETATTR
> message with the channel and essid attributes. Ultimately, we'll get rid
> of this, so a userspace tool using the netlink configuration would just
> tell the user via _GETATTRGROUP which attributes make sense to group
> together for optimal card behaviour.
> 
> As for the inject command, it looks like on the current wmgmt# interface
> for d80211 has a bunch of implicit behaviour like looking into the
> transmitted frame to see what type it is etc. I'd like to get rid of it
> and stuff the information for that into ATTR_FLAGS instead.
> 
> Oh and of course we'll have a structure somewhere that drivers and
> stacks register with the module that provides this netlink interface.
> That module will then also multiplex the commands to the drivers/stacks.
> I have that mostly figured out.
> 
> Since it will be easy to tell if a specific driver/stack implements
> old-style wext or this new API we can allow drivers with both APIs to
> coexist for a while. I won't map the new API to the old wext one of
> course, but mapping the wext API to the new one we need anyway. Hence,
> we can change the wext code to call the new API if present and the old
> one otherwise (with a big fat printk), and then slowly migrate drivers
> over. Due to the reduced commit logic, it should become simpler too,
> even for old drivers.
> 
> Anyway, comments appreciated. If we can agree on this general framework
> I'll start implementing the groundwork and some of the rest for d80211
> soon.
> 
> johannes
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: proposal for new wireless configuration API

[Michael Buesch]

On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> o Separate attributes for channel and frequency

No, channel and freq is the same. It's just another name
for the same child. I would say we only want to deal with channel numbers
in the API. That's much easier, as we don't have to deal with this
fixed-point (or even floating point) mess. Look at WE for the
fixed-point mess.
The userspace tools can easily convert freq to channel and back.
And in the kernel, we can easily provide some small function
to convert from channel to khz and back, for example. But I would
like to see the fixed-point stuff in the API vanish.

> o Method of finding out channel <-> frequency mapping (not all drivers
> support this in the SIOCGIWRANGE handler now)

Yes, that would be a good idea.
Comes next to the conversion function (see above).

-- 
Greetings Michael.

Re: proposal for new wireless configuration API

[Dan Williams]

On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > o Separate attributes for channel and frequency
> 
> No, channel and freq is the same. It's just another name
> for the same child. I would say we only want to deal with channel numbers
> in the API. That's much easier, as we don't have to deal with this
> fixed-point (or even floating point) mess. Look at WE for the
> fixed-point mess.

Right, I don't have a problem with only using one or the other; but we
_HAVE_ to provide a function in the driver that allows userspace
programs to convert channel <-> frequency both ways, like you suggest
below.  Obviously the channel/frequency mapping isn't the same
everywhere.

[ or is it?  I'd be very uncomfortable using the same channel #s
everywhere unless some IEEE spec states exactly what the channel #s are
for every frequency range that wireless stuff operates in ]

> The userspace tools can easily convert freq to channel and back.
> And in the kernel, we can easily provide some small function
> to convert from channel to khz and back, for example. But I would
> like to see the fixed-point stuff in the API vanish.

No argument here; as long as we provide the mapping function in the
driver for each card.

> > o Method of finding out channel <-> frequency mapping (not all drivers
> > support this in the SIOCGIWRANGE handler now)
> 
> Yes, that would be a good idea.
> Comes next to the conversion function (see above).

Yep.

Dan

Re: proposal for new wireless configuration API

[Michael Buesch]

On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > > o Separate attributes for channel and frequency
> > 
> > No, channel and freq is the same. It's just another name
> > for the same child. I would say we only want to deal with channel numbers
> > in the API. That's much easier, as we don't have to deal with this
> > fixed-point (or even floating point) mess. Look at WE for the
> > fixed-point mess.
> 
> Right, I don't have a problem with only using one or the other; but we
> _HAVE_ to provide a function in the driver that allows userspace
> programs to convert channel <-> frequency both ways, like you suggest
> below.  Obviously the channel/frequency mapping isn't the same
> everywhere.
> 
> [ or is it?  I'd be very uncomfortable using the same channel #s
> everywhere unless some IEEE spec states exactly what the channel #s are
> for every frequency range that wireless stuff operates in ]

The channel<->freq mapping is stable.
What is unstable is the allowed channels map.
For APHY there are even many gaps in the map. For example
channels 6, 40 and 55 may be the only ones allowed

(6, 40, 55 are generated by my /brain/random device ;) )

The frequency range you mention is selected differently by
another config option. In d80211 we call it the PHYMODE.
Switching the PHYMODE changes the meaning of channel values
and changes the output of the two functions below.

So if I want to switch to channel 4 in the 2.4Ghz band, I would do:
select PHYMODE B or G,
select channel 4.

That would lead to the card tuning to 2427 MHz.

> > The userspace tools can easily convert freq to channel and back.
> > And in the kernel, we can easily provide some small function
> > to convert from channel to khz and back, for example. But I would
> > like to see the fixed-point stuff in the API vanish.
> 
> No argument here; as long as we provide the mapping function in the
> driver for each card.

Hm, I don't know if I understand this correctly.
You want to implement the mapping function in every driver
or in the d80211 stack?
It belongs into a central place in the 80211 stack. There where
regulatory domain stuff is managed, too.


We need functions like:

u32 ieee80211_channel_to_freq(struct ieee80211 *ieee, u8 channel);
u8 ieee80211_freq_to_channel(struct ieee80211 *ieee, u32 channel);

These would be used in drivers to convert values.
The validity of the channel value passed from userspace would be
checked in the _stack_. If the user passes an illegal value for
his country, it would never reach the driver.

-- 
Greetings Michael.

RE: proposal for new wireless configuration API

[Simon Barber]

A further complication happens in Japan with 802.11j, and now in the USA
too - with 802.11y in the 3.65Ghz band - here there are some new channel
widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for
OFDM modulations - 11a/g, 22 for 11b). In Japan's 4.9Ghz band you can
run the OFDM at half rate, giving a 10Mhz wide channel, or at quarter
rate, giving a 5Mhz wide channel. Hence same frequency, different
channel spec. Using a channel number is the way to go. If we need
something to convert between the 2 it should probably be a library in
user space (in hostapd or wpa_supplicant) - hostapd does have this
today.

It might be nice if other applications could access this data too - but
I don't think it needs to be inside the kernel.

Simon

-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Michael Buesch
Sent: Tuesday, August 15, 2006 12:13 PM
To: Dan Williams
Cc: netdev@vger.kernel.org; Jean Tourrilhes; Johannes Berg
Subject: Re: proposal for new wireless configuration API

On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > > o Separate attributes for channel and frequency
> > 
> > No, channel and freq is the same. It's just another name for the 
> > same child. I would say we only want to deal with channel numbers in

> > the API. That's much easier, as we don't have to deal with this 
> > fixed-point (or even floating point) mess. Look at WE for the 
> > fixed-point mess.
> 
> Right, I don't have a problem with only using one or the other; but we

> _HAVE_ to provide a function in the driver that allows userspace 
> programs to convert channel <-> frequency both ways, like you suggest 
> below.  Obviously the channel/frequency mapping isn't the same 
> everywhere.
> 
> [ or is it?  I'd be very uncomfortable using the same channel #s 
> everywhere unless some IEEE spec states exactly what the channel #s 
> are for every frequency range that wireless stuff operates in ]

The channel<->freq mapping is stable.
What is unstable is the allowed channels map.
For APHY there are even many gaps in the map. For example channels 6, 40
and 55 may be the only ones allowed

(6, 40, 55 are generated by my /brain/random device ;) )

The frequency range you mention is selected differently by another
config option. In d80211 we call it the PHYMODE.
Switching the PHYMODE changes the meaning of channel values and changes
the output of the two functions below.

So if I want to switch to channel 4 in the 2.4Ghz band, I would do:
select PHYMODE B or G,
select channel 4.

That would lead to the card tuning to 2427 MHz.

> > The userspace tools can easily convert freq to channel and back.
> > And in the kernel, we can easily provide some small function to 
> > convert from channel to khz and back, for example. But I would like 
> > to see the fixed-point stuff in the API vanish.
> 
> No argument here; as long as we provide the mapping function in the 
> driver for each card.

Hm, I don't know if I understand this correctly.
You want to implement the mapping function in every driver or in the
d80211 stack?
It belongs into a central place in the 80211 stack. There where
regulatory domain stuff is managed, too.


We need functions like:

u32 ieee80211_channel_to_freq(struct ieee80211 *ieee, u8 channel);
u8 ieee80211_freq_to_channel(struct ieee80211 *ieee, u32 channel);

These would be used in drivers to convert values.
The validity of the channel value passed from userspace would be checked
in the _stack_. If the user passes an illegal value for his country, it
would never reach the driver.

--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

Re: proposal for new wireless configuration API

[Michael Buesch]

On Tuesday 15 August 2006 21:27, Simon Barber wrote:
> A further complication happens in Japan with 802.11j, and now in the USA
> too - with 802.11y in the 3.65Ghz band - here there are some new channel
> widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for
> OFDM modulations - 11a/g, 22 for 11b). In Japan's 4.9Ghz band you can
> run the OFDM at half rate, giving a 10Mhz wide channel, or at quarter
> rate, giving a 5Mhz wide channel. Hence same frequency, different
> channel spec. Using a channel number is the way to go. If we need
> something to convert between the 2 it should probably be a library in
> user space (in hostapd or wpa_supplicant) - hostapd does have this
> today.
>
> It might be nice if other applications could access this data too - but
> I don't think it needs to be inside the kernel.

We need this conversion function, as most devices tune to frequencies,
not channels. So when a driver is instructed to tune to channel 2,
it must call back into the 80211 stack to ask for the frequency (based
on the current PHYMODE and the other parameters you mentioned above).
That call should IMO not result in a call to userspace. Userspace
should instead set flags _before_ in the stack and the conversion
callback would act on these flags.
That way userspace only has to tell the kernel once which frequency-band,
half, quater freq, or whatever it wants. The actual conversion
from channel number to freq (or the other way around) is trivial after
that, as it's only a few ifs and elses based on some cheap flags.

-- 
Greetings Michael.

Re: proposal for new wireless configuration API

[Dan Williams]

On Tue, 2006-08-15 at 21:13 +0200, Michael Buesch wrote:
> On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> > On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > > On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > > > o Separate attributes for channel and frequency
> > > 
> > > No, channel and freq is the same. It's just another name
> > > for the same child. I would say we only want to deal with channel numbers
> > > in the API. That's much easier, as we don't have to deal with this
> > > fixed-point (or even floating point) mess. Look at WE for the
> > > fixed-point mess.
> > 
> > Right, I don't have a problem with only using one or the other; but we
> > _HAVE_ to provide a function in the driver that allows userspace
> > programs to convert channel <-> frequency both ways, like you suggest
> > below.  Obviously the channel/frequency mapping isn't the same
> > everywhere.
> > 
> > [ or is it?  I'd be very uncomfortable using the same channel #s
> > everywhere unless some IEEE spec states exactly what the channel #s are
> > for every frequency range that wireless stuff operates in ]
> 
> The channel<->freq mapping is stable.

Ok, so if somebody magically opens up new unlicensed ISM spectrum
around, say, 7GHz, does that space get broken into channels and assigned
specific numbers by the IEEE?

I know there are stable channel #s for abg range.  What about the
future? [1]  Can we guarantee that whenever new spectrum opens up that
future 802.11 products may use, that the mappings are well-defined?

That was my main question.

> What is unstable is the allowed channels map.
> For APHY there are even many gaps in the map. For example
> channels 6, 40 and 55 may be the only ones allowed
> 
> (6, 40, 55 are generated by my /brain/random device ;) )
> 
> The frequency range you mention is selected differently by
> another config option. In d80211 we call it the PHYMODE.
> Switching the PHYMODE changes the meaning of channel values
> and changes the output of the two functions below.
> 
> So if I want to switch to channel 4 in the 2.4Ghz band, I would do:
> select PHYMODE B or G,
> select channel 4.
> 
> That would lead to the card tuning to 2427 MHz.

That sounds fine to me.

> > > The userspace tools can easily convert freq to channel and back.
> > > And in the kernel, we can easily provide some small function
> > > to convert from channel to khz and back, for example. But I would
> > > like to see the fixed-point stuff in the API vanish.
> > 
> > No argument here; as long as we provide the mapping function in the
> > driver for each card.
> 
> Hm, I don't know if I understand this correctly.
> You want to implement the mapping function in every driver
> or in the d80211 stack?

If we can assume that future spectrum will have well-defined channel
numbers, then I don't have a problem with having the mapping function
_once_ in d80211.

Will the d80211 stack _only_ be used for 802.11 [a|b|g|n]
implementations?  What if another implementation comes around that uses
a different PHY but the same spectrum and same protocol?  Ultrawide Band
using 802.11 protocol or something?  Who knows?

> It belongs into a central place in the 80211 stack. There where
> regulatory domain stuff is managed, too.

No argument there.  I'm just wondering aloud if we can guarantee that
the mappings will always be the same for stuff other than 802.11[abgn].
Originally, Linux Wireless Extensions was designed with stuff in
addition to 802.11.  It happened that 802.11 is pretty much the only
thing that uses WE.  Since d80211 is by nature an _802.11_ stack, it's
fine to restrict the configuration to 802.11 stuff.  But we can't
necessarily say what every 802.11 substandard is going to do with
channels and spectrum in the future, can we?  Making the mapping API
flexible is one way to ensure that we don't get stuck a WE-type trap.

Dan

[1]  Obviously we cannot ever anticipate everything, and nobody should
try to excessively future-proof d80211, or nothing will get done.  We
need to balance extendability with over-anticipation.

Re: proposal for new wireless configuration API

[Dan Williams]

On Tue, 2006-08-15 at 21:35 +0200, Michael Buesch wrote:
> On Tuesday 15 August 2006 21:27, Simon Barber wrote:
> > A further complication happens in Japan with 802.11j, and now in the USA
> > too - with 802.11y in the 3.65Ghz band - here there are some new channel
> > widths that are possible. Normally 802.11 is 20 or 22Mhz wide (20Mhz for
> > OFDM modulations - 11a/g, 22 for 11b). In Japan's 4.9Ghz band you can
> > run the OFDM at half rate, giving a 10Mhz wide channel, or at quarter
> > rate, giving a 5Mhz wide channel. Hence same frequency, different
> > channel spec. Using a channel number is the way to go. If we need
> > something to convert between the 2 it should probably be a library in
> > user space (in hostapd or wpa_supplicant) - hostapd does have this
> > today.
> >
> > It might be nice if other applications could access this data too - but
> > I don't think it needs to be inside the kernel.
> 
> We need this conversion function, as most devices tune to frequencies,
> not channels. So when a driver is instructed to tune to channel 2,
> it must call back into the 80211 stack to ask for the frequency (based
> on the current PHYMODE and the other parameters you mentioned above).
> That call should IMO not result in a call to userspace. Userspace
> should instead set flags _before_ in the stack and the conversion
> callback would act on these flags.
> That way userspace only has to tell the kernel once which frequency-band,
> half, quater freq, or whatever it wants. The actual conversion
> from channel number to freq (or the other way around) is trivial after
> that, as it's only a few ifs and elses based on some cheap flags.

As long as there's a way for userspace to convert channel <-> frequency
and back using the _same_ values as the driver is using, that's all I
care about.  I just don't want to have each userspace program have its
own library of channel/frequency mappings simply because not enough
information was exposed through the d80211 stack's API.

Dan

Re: proposal for new wireless configuration API

[Johannes Berg]

On Tue, 2006-08-15 at 12:29 -0400, Dan Williams wrote:

> We might want to take the time to fix up a few of the ambiguities of
> WEXT that we've encountered over the past few years:

Yes, I definitely agree.

> o Separate attributes for signal strength units; signed integer type for
> dBm, unsigned integer type for RSSI.  One 8-bit var to represent both is
> just too confusing for people, evidently (which is true...)

Yes, agreed, they should be separated. In general, I think that one
attribute should always have a single meaning and unit attached, except
for explicitly unit-less attributes (number of frames or whatever), or
attributes that explicitly have no stable unit (raw rssi).

> o Merge functionality ENCODE and ENCODEEXT handlers into one

Good one. I'm still not sure whether we should have an attribute for
this, or a command. The whole key business seems rather complex and it
might be good to have a command 'set key' with say a possible attribute
for the mac address of a pairwise key, a key material attribute and an
IV attribute or something. Otherwise we'll end up parsing the contents
of an attribute again, which rather sucks...

On the other hand, having it as a command won't allow the user to
optimize setting the key and other things at once. I'm not too sure we
should pay all that much attention to this problem though, it can't take
forever and typically a user with such a card won't be changing the key
or parameters all the time, hence it's usually probably done only at boo
or association time.

johannes

Re: proposal for new wireless configuration API

[Johannes Berg]

On Tue, 2006-08-15 at 15:59 -0400, Dan Williams wrote:

> Ok, so if somebody magically opens up new unlicensed ISM spectrum
> around, say, 7GHz, does that space get broken into channels and assigned
> specific numbers by the IEEE?
> 
> I know there are stable channel #s for abg range.  What about the
> future? [1]  Can we guarantee that whenever new spectrum opens up that
> future 802.11 products may use, that the mappings are well-defined?
> 
> That was my main question.

I'd expect them to actually break it into channels and assign channel
numbers. Or whoever creates the hardware first does it, and those
numbers then get adopted in the year-long specification process ;)

Besides, if we really really really needed something else later for
whatever weird reason, we could add a new attribute for those cases, and
have it reject the channel attribute then :)

johannes

Re: proposal for new wireless configuration API

[Johannes Berg]

On Tue, 2006-08-15 at 12:14 -0400, Luis R. Rodriguez wrote:

> Basically redo WE completely from scratch using netlink.

Not quite, I hope! As Dan mentioned, for example all the key management
stuff ought to be consolidated. Same for some other things.

> For per packet this makes sense, for modification of all packets I
> think configfs would be more suitable. Then again this is just an
> addition, I'm not disagreeing here with the approach. The same goes
> for several common wireless settings -- we could also have a configfs
> directory for each device which would allow manual read/writing for
> setting/getting certain values; mind you that congifs does allow for
> setting/getting multiple values at the same time, for those of you who
> have wondered. This could just could easily go in as a wrapper for
> configfs->new NL API.

Yeah, that might not even be undesirable. But we also need per-packet
controls, and a bunch of them. The current situation with a special
header in front of a packet injected into the management interface isn't
too great.

I'm not sure what kind of generic packet sending parameters we have.
Bitrate obviously, and all the other possible attributes...

> >    NL80211_ATTR_IFINDEX: index of interface to use

This was just meant to be the ifindex of the eth0 or whatever device.

> >    (NL80211_ATTR_PHYIDX: (later) index of wiphy to configure)
> 
> Do you mean to have a wireless device have its own device index,
> separate from the netdevice index? Can you elaborate a bit on this?

Well, the d80211 stack gives each driver backend phyN
in /sys/class/ieee80211/. If we ever want to get rid of the wmasterN
interface, we probably want to allow configuring without an ifindex
because the physical device might not have any network devices attached
at that time. I'm not exactly sure if it really makes sense to configure
the device then, but hey.

> With WE we were restricted to the number of attributes possibly
> changed by the number of ioctls and later by sub-ioctl hack
> restrictions. What restrictions are we to face with this? 

We can have tons of attributes, it's a 16-bit field. I think that should
be sufficient :)

> Do we want
> to map each attribute directly to the respective WE ioctl number to
> make it easy to do backward compatibility?

No, because that would mean having very large attribute numbers
up-front, and due to the way genetlink works there is memory allocated
for each possible attribute. Hence, attribute numbers should be
allocated in an increasing fashion starting from 1, and not be sparse.

johannes

RE: proposal for new wireless configuration API

[Simon Barber]

I'd suggest that the new signal strength measure should be defined as
'RCPI' - the 'Received Channel Power Indicator' - which is defined in
IEEE 802.11k (the Radio Measurements amendment to 802.11).  Here is the
full text of the definition from 802.11k draft 5.0:

received channel power indicator (RCPI): An indication of the total
channel power (signal, noise, and interference) of a received IEEE
802.11 frame measured on a single channel and at the antenna connector
used to receive the frame.

The RCPI indicator is a measure of the received RF power in the selected
channel for a received frame. This parameter shall be a measure by the
PHY sublayer of the received RF power in the channel measured over the
entire received frame or by other equivalent means which meet the
specified accuracy. RCPI shall be a monotonically increasing,
logarithmic function of the received power level defined in dBm. The
allowed values for the Received Channel Power Indicator (RCPI) parameter
shall be an 8 bit value in the range from 0 through 220, with indicated
values rounded to the nearest 0.5 dB as follows:

0: Power < -110 dBm
1: Power = -109.5 dBm
2: Power = -109.0 dBm

and so on where

RCPI = int{(Power in dBm +110)*2} for 0dbm > Power > -110dBm

220: Power > -0 dBm
221-254: reserved
255: Measurement not available

RCPI shall equal the received RF power within an accuracy of +/-5 dB
(95% confidence interval) within the specified dynamic range of the
receiver. The received RF power shall be determined assuming a receiver
noise equivalent bandwidth equal to the channel bandwidth multiplied by
1.1.



Simon

-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of Johannes Berg
Sent: Tuesday, August 15, 2006 11:51 PM
To: Dan Williams
Cc: netdev@vger.kernel.org; Jean Tourrilhes
Subject: Re: proposal for new wireless configuration API

On Tue, 2006-08-15 at 12:29 -0400, Dan Williams wrote:

> We might want to take the time to fix up a few of the ambiguities of 
> WEXT that we've encountered over the past few years:

Yes, I definitely agree.

> o Separate attributes for signal strength units; signed integer type 
> for dBm, unsigned integer type for RSSI.  One 8-bit var to represent 
> both is just too confusing for people, evidently (which is true...)

Yes, agreed, they should be separated. In general, I think that one
attribute should always have a single meaning and unit attached, except
for explicitly unit-less attributes (number of frames or whatever), or
attributes that explicitly have no stable unit (raw rssi).

> o Merge functionality ENCODE and ENCODEEXT handlers into one

Good one. I'm still not sure whether we should have an attribute for
this, or a command. The whole key business seems rather complex and it
might be good to have a command 'set key' with say a possible attribute
for the mac address of a pairwise key, a key material attribute and an
IV attribute or something. Otherwise we'll end up parsing the contents
of an attribute again, which rather sucks...

On the other hand, having it as a command won't allow the user to
optimize setting the key and other things at once. I'm not too sure we
should pay all that much attention to this problem though, it can't take
forever and typically a user with such a card won't be changing the key
or parameters all the time, hence it's usually probably done only at boo
or association time.

johannes
-
To unsubscribe from this list: send the line "unsubscribe netdev" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

RE: proposal for new wireless configuration API

[Johannes Berg]

On Wed, 2006-08-16 at 11:02 -0700, Simon Barber wrote:
> I'd suggest that the new signal strength measure should be defined as
> 'RCPI' - the 'Received Channel Power Indicator' - which is defined in
> IEEE 802.11k (the Radio Measurements amendment to 802.11).

Except that we unfortunately have no way of getting this with all the
reverse engineered devices :) Hence, I guess we should then have
multiple different possibilities. A device reporting RCPI would be
better than just reporting RSSI, but that's still better than nothing...

johannes

RE: proposal for new wireless configuration API

[Simon Barber]

The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number,
guaranteed to be a monotonically increasing function of signal strength.
You don't get to know anything about the scale, or linearity of the
function. In essence RSSI is a vendor specific value, of no known units.
Not very useful unless you know some card specific details to help
interpret it.

Now some cards return a signal strength in dBm as the RSSI - note that
this fits the requirements of a RSSI measure just fine. RCPI is simply a
more tightly specified signal strength measure.

Just saying that a RSSI value is not very useful.

Simon
 

-----Original Message-----
From: Johannes Berg [mailto:johannes@sipsolutions.net] 
Sent: Thursday, August 17, 2006 12:20 AM
To: Simon Barber
Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes
Subject: RE: proposal for new wireless configuration API

On Wed, 2006-08-16 at 11:02 -0700, Simon Barber wrote:
> I'd suggest that the new signal strength measure should be defined as 
> 'RCPI' - the 'Received Channel Power Indicator' - which is defined in 
> IEEE 802.11k (the Radio Measurements amendment to 802.11).

Except that we unfortunately have no way of getting this with all the
reverse engineered devices :) Hence, I guess we should then have
multiple different possibilities. A device reporting RCPI would be
better than just reporting RSSI, but that's still better than nothing...

johannes

Re: proposal for new wireless configuration API

[Jean Tourrilhes]

On Tue, Aug 15, 2006 at 09:13:23PM +0200, Michael Buesch wrote:
> On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> > On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > > On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > > > o Separate attributes for channel and frequency
> > > 
> > > No, channel and freq is the same. It's just another name
> > > for the same child. I would say we only want to deal with channel numbers
> > > in the API. That's much easier, as we don't have to deal with this
> > > fixed-point (or even floating point) mess. Look at WE for the
> > > fixed-point mess.
> > 
> > Right, I don't have a problem with only using one or the other; but we
> > _HAVE_ to provide a function in the driver that allows userspace
> > programs to convert channel <-> frequency both ways, like you suggest
> > below.  Obviously the channel/frequency mapping isn't the same
> > everywhere.
> > 
> > [ or is it?  I'd be very uncomfortable using the same channel #s
> > everywhere unless some IEEE spec states exactly what the channel #s are
> > for every frequency range that wireless stuff operates in ]
> 
> The channel<->freq mapping is stable.

	We may need to double check this...
	It is already clear that WiMax, ZigBee and pre-802.11 HW don't
use the same channel<->freq mapping as 802.11.
	Further, I remember somebody (was it Jouni) mentioning that
some variations of 802.11 have different channel mappings. But, we
would need to check that.

> > No argument here; as long as we provide the mapping function in the
> > driver for each card.
> 
> Hm, I don't know if I understand this correctly.
> You want to implement the mapping function in every driver
> or in the d80211 stack?

	A simple mapping table is probably enough, similar to what we
already have.

	Jean

Re: proposal for new wireless configuration API

[Michael Buesch]

On Thursday 17 August 2006 21:39, Jean Tourrilhes wrote:
> On Tue, Aug 15, 2006 at 09:13:23PM +0200, Michael Buesch wrote:
> > On Tuesday 15 August 2006 20:14, Dan Williams wrote:
> > > On Tue, 2006-08-15 at 18:38 +0200, Michael Buesch wrote:
> > > > On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > > > > o Separate attributes for channel and frequency
> > > > 
> > > > No, channel and freq is the same. It's just another name
> > > > for the same child. I would say we only want to deal with channel numbers
> > > > in the API. That's much easier, as we don't have to deal with this
> > > > fixed-point (or even floating point) mess. Look at WE for the
> > > > fixed-point mess.
> > > 
> > > Right, I don't have a problem with only using one or the other; but we
> > > _HAVE_ to provide a function in the driver that allows userspace
> > > programs to convert channel <-> frequency both ways, like you suggest
> > > below.  Obviously the channel/frequency mapping isn't the same
> > > everywhere.
> > > 
> > > [ or is it?  I'd be very uncomfortable using the same channel #s
> > > everywhere unless some IEEE spec states exactly what the channel #s are
> > > for every frequency range that wireless stuff operates in ]
> > 
> > The channel<->freq mapping is stable.
> 
> 	We may need to double check this...
> 	It is already clear that WiMax, ZigBee and pre-802.11 HW don't
> use the same channel<->freq mapping as 802.11.
> 	Further, I remember somebody (was it Jouni) mentioning that
> some variations of 802.11 have different channel mappings. But, we
> would need to check that.

Yes, I should have been more verbose here.
What I meant is: In a particular PHYMODE the channel->freq mapping
is stable. That is, if we are in G-PHY mode, the mapping is always
stable with channels 1-14. Wimax and so on would be another PHYMODE.
The PHYMODE would be selected otherwise (through other netlink attrs
or whatever).

> > > No argument here; as long as we provide the mapping function in the
> > > driver for each card.
> > 
> > Hm, I don't know if I understand this correctly.
> > You want to implement the mapping function in every driver
> > or in the d80211 stack?
> 
> 	A simple mapping table is probably enough, similar to what we
> already have.

Well, a mapping function, because we must look at the different PHYMODEs.

-- 
Greetings Michael.

Re: proposal for new wireless configuration API

[Ulrich Kunitz]

On 06-08-17 09:42 Simon Barber wrote:

> The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number,
> guaranteed to be a monotonically increasing function of signal strength.
> You don't get to know anything about the scale, or linearity of the
> function. In essence RSSI is a vendor specific value, of no known units.
> Not very useful unless you know some card specific details to help
> interpret it.
> 
> Now some cards return a signal strength in dBm as the RSSI - note that
> this fits the requirements of a RSSI measure just fine. RCPI is simply a
> more tightly specified signal strength measure.
> 
> Just saying that a RSSI value is not very useful.

we are simply not able to deliver RCPI, because we have no idea
how RSSI is measured for the ZD1211 device. We had discussions with the
vendor developers, but it seemed that their understanding was not
really more advanced than our's.

There is the same issue for signal quality and signal-to-noise
ratio.

-- 
Uli Kunitz

Re: proposal for new wireless configuration API

[Ulrich Kunitz]

On 06-08-15 18:38 Michael Buesch wrote:

> On Tuesday 15 August 2006 18:29, Dan Williams wrote:
> > o Separate attributes for channel and frequency
> 
> No, channel and freq is the same. It's just another name
> for the same child. I would say we only want to deal with channel numbers
> in the API. That's much easier, as we don't have to deal with this
> fixed-point (or even floating point) mess. Look at WE for the
> fixed-point mess.
> The userspace tools can easily convert freq to channel and back.
> And in the kernel, we can easily provide some small function
> to convert from channel to khz and back, for example. But I would
> like to see the fixed-point stuff in the API vanish.
> 
> > o Method of finding out channel <-> frequency mapping (not all drivers
> > support this in the SIOCGIWRANGE handler now)
> 
> Yes, that would be a good idea.
> Comes next to the conversion function (see above).

Channel to frequency mapping is defined by 802.11. So we could get
rid of frequencies totally in the user interface and it will also
help with compliance to regulatory rules. Or are here people, who
really want to freely transmit on all frequencies their RF might
be able to generate?

-- 
Uli Kunitz

RE: proposal for new wireless configuration API

[Johannes Berg]

On Thu, 2006-08-17 at 09:42 -0700, Simon Barber wrote:
> The spec for RSSI is very loose - RSSI is just a 8 bit unsigned number,
> guaranteed to be a monotonically increasing function of signal strength.
> You don't get to know anything about the scale, or linearity of the
> function. In essence RSSI is a vendor specific value, of no known units.
> Not very useful unless you know some card specific details to help
> interpret it.

Yeah, if you knew at least linearity it'd be more useful.

> Now some cards return a signal strength in dBm as the RSSI - note that
> this fits the requirements of a RSSI measure just fine. RCPI is simply a
                                  ^^^^
did you mean to write RCPI there?

> more tightly specified signal strength measure.

Ah, ok. Yes, I think we almost know how to make the bcm card report dBm
instead.

johannes

Re: proposal for new wireless configuration API

[Johannes Berg]

On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote:
> Or are here people, who
> really want to freely transmit on all frequencies their RF might
> be able to generate?

Yes :P
Some amateur radio people asked me about extending the spectrum a bit to
the top (apparently they're allowed to use the band just above the ISM
band as well).

However, I don't think we need to cater them in the API. I think they
ought to be able to live with kernel patches since we don't really know
how far up the frequency on say the bcm43xx can go anyway before the
card breaks/malfunctions.

johannes

Re: proposal for new wireless configuration API

[John W. Linville]

On Fri, Aug 18, 2006 at 09:12:05AM +0200, Johannes Berg wrote:
> On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote:
> > Or are here people, who
> > really want to freely transmit on all frequencies their RF might
> > be able to generate?
> 
> Yes :P
> Some amateur radio people asked me about extending the spectrum a bit to
> the top (apparently they're allowed to use the band just above the ISM
> band as well).
> 
> However, I don't think we need to cater them in the API. I think they
> ought to be able to live with kernel patches since we don't really know
> how far up the frequency on say the bcm43xx can go anyway before the
> card breaks/malfunctions.

I concur.  It would be best to confine the "normal" API to things
that are legitimately done without a license if at all possible.
Those who are licensed for other spectrum uses should be more than
capable of applying a patch to do so (thereby more clearly taking
regulatory responsibility upon themselves).

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

RE: proposal for new wireless configuration API

[Simon Barber]

I did mean RSSI - just about anything that when interpreted as an 8 bit
unsigned int and goes up with increasing signal fits the bill as an RSSI
measure. RCPI requires a certain minimum accuracy and linearity (the
accuracy required is not very high).

Simon


-----Original Message-----
From: Johannes Berg [mailto:johannes@sipsolutions.net] 
Sent: Friday, August 18, 2006 12:02 AM
To: Simon Barber
Cc: Dan Williams; netdev@vger.kernel.org; Jean Tourrilhes
Subject: RE: proposal for new wireless configuration API

On Thu, 2006-08-17 at 09:42 -0700, Simon Barber wrote:
> The spec for RSSI is very loose - RSSI is just a 8 bit unsigned 
> number, guaranteed to be a monotonically increasing function of signal
strength.
> You don't get to know anything about the scale, or linearity of the 
> function. In essence RSSI is a vendor specific value, of no known
units.
> Not very useful unless you know some card specific details to help 
> interpret it.

Yeah, if you knew at least linearity it'd be more useful.

> Now some cards return a signal strength in dBm as the RSSI - note that

> this fits the requirements of a RSSI measure just fine. RCPI is simply

> a
                                  ^^^^
did you mean to write RCPI there?

> more tightly specified signal strength measure.

Ah, ok. Yes, I think we almost know how to make the bcm card report dBm
instead.

johannes

Re: proposal for new wireless configuration API

[Ulrich Kunitz]

On 06-08-18 09:12 Johannes Berg wrote:

> On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote:
> > Or are here people, who
> > really want to freely transmit on all frequencies their RF might
> > be able to generate?
> 
> Yes :P
> Some amateur radio people asked me about extending the spectrum a bit to
> the top (apparently they're allowed to use the band just above the ISM
> band as well).

I had some discussions with radio amateurs about the RFs in the
ZD1211 devices. Even if I could transmit in their required bands,
the RFs are so WLAN specific, that they don't fulfill their
requirements. It's really funny, if somebody explains to you that
these chips are of extremely low quality. I always try to explain
to them that the complete devices are sold for only 17 Euros
including VAT. You cannot expect for this price the quality
required for long range transmissions at these high frequencies.

I support the idea that radio amateurs should create their own
patches if they need it. Supporting the frequencies in the
interface, is a typical feature used by less than 1% of the user
base, but would cost more than 80% of the effort. We should also not
do anything, which would raise the impression, that we want to
ignore regulatory rules.

> However, I don't think we need to cater them in the API. I think they
> ought to be able to live with kernel patches since we don't really know
> how far up the frequency on say the bcm43xx can go anyway before the
> card breaks/malfunctions.

Do they have a separate RF? They data sheets are usually
available, even if the not always explain the register
programming.

-- 
Uli Kunitz

Re: proposal for new wireless configuration API

[Michael Buesch]

On Friday 18 August 2006 23:29, Ulrich Kunitz wrote:
> On 06-08-18 09:12 Johannes Berg wrote:
> 
> > On Fri, 2006-08-18 at 01:29 +0200, Ulrich Kunitz wrote:
> > > Or are here people, who
> > > really want to freely transmit on all frequencies their RF might
> > > be able to generate?
> > 
> > Yes :P
> > Some amateur radio people asked me about extending the spectrum a bit to
> > the top (apparently they're allowed to use the band just above the ISM
> > band as well).
> 
> I had some discussions with radio amateurs about the RFs in the
> ZD1211 devices. Even if I could transmit in their required bands,
> the RFs are so WLAN specific, that they don't fulfill their
> requirements. It's really funny, if somebody explains to you that
> these chips are of extremely low quality. I always try to explain
> to them that the complete devices are sold for only 17 Euros
> including VAT. You cannot expect for this price the quality
> required for long range transmissions at these high frequencies.
> 
> I support the idea that radio amateurs should create their own
> patches if they need it. Supporting the frequencies in the
> interface, is a typical feature used by less than 1% of the user
> base, but would cost more than 80% of the effort. We should also not
> do anything, which would raise the impression, that we want to
> ignore regulatory rules.

I second that.
We should not allow to drive devices outside of the specs.
If someone wants to do this, he should be able to apply a one-liner
patch to tune to some different frequency. ;)

> > However, I don't think we need to cater them in the API. I think they
> > ought to be able to live with kernel patches since we don't really know
> > how far up the frequency on say the bcm43xx can go anyway before the
> > card breaks/malfunctions.
> 
> Do they have a separate RF? They data sheets are usually
> available, even if the not always explain the register
> programming.

We currently know 6 different radio chips used by bcm43xx:
http://bcm-specs.sipsolutions.net/RadioID

AFAIK the chip is from broadcom, too. I don't like to check
now, as that would require to disassemble my AP and look at
the chip. ;) But I'm pretty sure.
There is no datasheet available for the chip. At least nobody
was able to get or found one so far... .

-- 
Greetings Michael.

RE: proposal for new wireless configuration API

[Johannes Berg]

On Fri, 2006-08-18 at 09:45 -0700, Simon Barber wrote:
> I did mean RSSI - just about anything that when interpreted as an 8 bit
> unsigned int and goes up with increasing signal fits the bill as an RSSI
> measure. RCPI requires a certain minimum accuracy and linearity (the
> accuracy required is not very high).

Ah got it now, sorry. Yes, good point.

Thanks for explaining,
johannes

Re: proposal for new wireless configuration API

[Johannes Berg]

On Sat, 2006-08-19 at 00:02 +0200, Michael Buesch wrote:

> We currently know 6 different radio chips used by bcm43xx:
> http://bcm-specs.sipsolutions.net/RadioID
> 
> AFAIK the chip is from broadcom, too.

It is, and there is no datasheet.

See http://johannes.sipsolutions.net/files/asus-wl100g.png :)

johannes