your nl80211 work

your nl80211 work

[Johannes Berg]

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

Hey,

Just saw on IRC that you linked to
http://git.spaceboyz.net/nl80211/nl80211-dev.git and took a quick look.

Some comments.

You say that

+ * @NL80211_CMD_GET_INTERFACE: request an interface's configuration.
+ *     either a dump request on a %NL80211_ATTR_WIPHY or a specific get
+ *      on a %NL80211_ATTR_IFINDEX is supported.

unfortunately, it can't be a dump request. The problem is that when you
have a dump request and possibly multiple virtual interfaces, and one of
them is controlled by the userspace MLME, then you need to call out to
the userspace MLME (via netlink too) to get the configuration. That,
however, can't be done while holding locks which would be required for
the dump request.

+       /* %input: wiphy */
+       NL80211_CMD_SET_CHANNEL,

The %... annotations were for my pynl80211 tool, feel free to leave them
off. In this case, it should probably be
 %input: wiphy, channel, phymode
but if you don't want to test it with pynl80211 don't bother.


+       int     (*get_channel)(struct wiphy *wiphy, int *chan, int *freq,
+                              enum nl80211_phymode *phymode);
+       int     (*set_channel)(struct wiphy *wiphy, int chan, int freq, /* XXX both?! */
+                              enum nl80211_phymode *phymode);

I don't think both are useful. Somewhere we need a library function to
convert from (chan, phymode) to frequency and back though. Although even
frequency isn't unique when you get to .11N or the atheros turbo foo.


+               case MODE_IEEE80211A:
+               case MODE_ATHEROS_TURBO:
+                       *phymode = NL80211_PHYMODE_A;

Are those Atheros Turbo modes actually useful these days in mac80211? If
so we probably should support them in nl80211 too, but I don't really
know, I guess Jouni is the only one who ever used them?

In any case, looks pretty good :)

johannes

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

Re: your nl80211 work

[David Lamparter]

Hi!

> + * @NL80211_CMD_GET_INTERFACE: request an interface's configuration.
> + *     either a dump request on a %NL80211_ATTR_WIPHY or a specific get
> + *      on a %NL80211_ATTR_IFINDEX is supported.
> 
> unfortunately, it can't be a dump request. The problem is that when you
> have a dump request and possibly multiple virtual interfaces, and one of
> them is controlled by the userspace MLME, then you need to call out to
> the userspace MLME (via netlink too) to get the configuration. That,
> however, can't be done while holding locks which would be required for
> the dump request.

Ah, I didn't think about that. Well, next try next luck... Hmm. Maybe we
should include the list of interfaces into the GET_WIPHY command and have
GET_INTERFACE never return a list?

> +       int     (*get_channel)(struct wiphy *wiphy, int *chan, int *freq,
> +                              enum nl80211_phymode *phymode);
> +       int     (*set_channel)(struct wiphy *wiphy, int chan, int freq, /* XXX both?! */
> +                              enum nl80211_phymode *phymode);
> 
> I don't think both are useful. Somewhere we need a library function to
> convert from (chan, phymode) to frequency and back though. Although even
> frequency isn't unique when you get to .11N or the atheros turbo foo.

Yeah, I was hoping for feedback on this one. For one, do we even bother to
return the frequency via nl80211? There's no attribute for it yet, and I
don't know if this is too useful. Maybe it can be included in the channel
list, so if an application really wants to know the frequency, it can look
up the table using channel+phymode as key and get it.

(channel list needs to be outlined next...)

> In any case, looks pretty good :)

Well, more or less. I messed up somewhere, a dump request for wiphys is
endlessly returning me the one wiphy I have, only aborting when I kill my
app. But, let's say I'm happy my box didn't explode. Guess I need to try
harder.


-David

Re: your nl80211 work

[Johannes Berg]

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

On Sat, 2007-06-09 at 13:39 +0200, David Lamparter wrote:

> Ah, I didn't think about that. Well, next try next luck... Hmm. Maybe we
> should include the list of interfaces into the GET_WIPHY command and have
> GET_INTERFACE never return a list?

Actually, I only thought about that yesterday too when thinking about
the userspace MLME thing (see my other post)

> Yeah, I was hoping for feedback on this one. For one, do we even bother to
> return the frequency via nl80211? There's no attribute for it yet, and I
> don't know if this is too useful. Maybe it can be included in the channel
> list, so if an application really wants to know the frequency, it can look
> up the table using channel+phymode as key and get it.

I think Dan said that he'd really like to see the kernel have a
frequency table somehow so not all userspace programs need to convert
themselves and introduce bugs and be updated all the time for new
things. But just having it in the channel list seems sufficient, or have
it in cfg80211 and pass it via nl80211 but not read it on incoming
requests nor bother the driver with it, i.e. create it from
channel/phymode in nl80211.c itself.

johannes

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

Re: your nl80211 work

[Dan Williams]

On Sat, 2007-06-09 at 14:14 +0200, Johannes Berg wrote:
> On Sat, 2007-06-09 at 13:39 +0200, David Lamparter wrote:
> 
> > Ah, I didn't think about that. Well, next try next luck... Hmm. Maybe we
> > should include the list of interfaces into the GET_WIPHY command and have
> > GET_INTERFACE never return a list?
> 
> Actually, I only thought about that yesterday too when thinking about
> the userspace MLME thing (see my other post)
> 
> > Yeah, I was hoping for feedback on this one. For one, do we even bother to
> > return the frequency via nl80211? There's no attribute for it yet, and I
> > don't know if this is too useful. Maybe it can be included in the channel
> > list, so if an application really wants to know the frequency, it can look
> > up the table using channel+phymode as key and get it.
> 
> I think Dan said that he'd really like to see the kernel have a
> frequency table somehow so not all userspace programs need to convert

Well, at least have one that all 802.11 _drivers_ can use at the very
least, I know of 5 or 6 places in the kernel right now that have this
sort of info.  Even just inlines in ieee80211.h or something for
chan->freq, freq->chan, freq->band, chan->band, etc.  Max allowed power
levels and stuff as well.

WRT to userspace, if there's an easy way to put this into headers that
get exported to userspace headers, I think that would be useful.
Otherwise everybody has to keep rewriting these, both mac80211, fullmac
drivers, userspace programs like NetworkManager and wpa_supplicant, etc.

Dan

> themselves and introduce bugs and be updated all the time for new
> things. But just having it in the channel list seems sufficient, or have
> it in cfg80211 and pass it via nl80211 but not read it on incoming
> requests nor bother the driver with it, i.e. create it from
> channel/phymode in nl80211.c itself.
> 
> johannes

Re: your nl80211 work

[Johannes Berg]

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

On Sat, 2007-06-09 at 09:54 -0400, Dan Williams wrote:

> Well, at least have one that all 802.11 _drivers_ can use at the very
> least, I know of 5 or 6 places in the kernel right now that have this
> sort of info.  Even just inlines in ieee80211.h or something for
> chan->freq, freq->chan, freq->band, chan->band, etc.  Max allowed power
> levels and stuff as well.

Right, that's something we need to clean up as well, but I don't want to
touch it before we have a concensus and more work on regulatory stuff.

> WRT to userspace, if there's an easy way to put this into headers that
> get exported to userspace headers, I think that would be useful.
> Otherwise everybody has to keep rewriting these, both mac80211, fullmac
> drivers, userspace programs like NetworkManager and wpa_supplicant, etc.

Right, except that when we add .11n or even .11y that'll require all
userspace tools to be rewritten, so wouldn't it be easier to export the
info via nl80211 right away?

johannes

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

Atheros Turbo modes / API [was: nl80211]

[David Lamparter]

> +               case MODE_IEEE80211A:
> +               case MODE_ATHEROS_TURBO:
> +                       *phymode = NL80211_PHYMODE_A;
> 
> Are those Atheros Turbo modes actually useful these days in mac80211? If
> so we probably should support them in nl80211 too, but I don't really
> know, I guess Jouni is the only one who ever used them?
> 

Jouni? Is this (a) still in use, and (b) how should it be made available to
userspace? We could either add additional modes to nl80211_phymode -or- add
a NL80211_ATTR_ATHEROS_TURBO as boolean tag -or- plunge it into debugfs...


-David

Re: Atheros Turbo modes / API [was: nl80211]

[Jouni Malinen]

On Sat, Jun 09, 2007 at 01:49:07PM +0200, David Lamparter wrote:
> > +               case MODE_ATHEROS_TURBO:

> > Are those Atheros Turbo modes actually useful these days in mac80211? If
> > so we probably should support them in nl80211 too, but I don't really
> > know, I guess Jouni is the only one who ever used them?

> Jouni? Is this (a) still in use, and (b) how should it be made available to
> userspace? We could either add additional modes to nl80211_phymode -or- add
> a NL80211_ATTR_ATHEROS_TURBO as boolean tag -or- plunge it into debugfs...

Well, some people may use Atheros Turbo mode, but taken into account
that this is a vendor specific extension and 802.11n will take care of
similar enhancements in a standard way, I don't think there is much
point in trying to maintain any level of support for these in mac80211.

For this reason, most of the Atheros specific stuff was already removed
and only some references to the special channels remained. I haven't
bothered importing support for these into hostapd either. Consequently,
I would just go ahead and remove all references to MODE_ATHEROS_TURBO,
MODE_ATHEROS_TURBOG, and related functionality and comments from
mac80211.

-- 
Jouni Malinen                                            PGP id EFC895FA