Hi list, Hi Johannes,
together with a friend of mine, I recently pondered about making linux
wireless configuration utilities more friendly to use. He did some
hacking to add wext to iproute2, but got "use nl80211" as reply. (cf.
http://marc.info/?l=linux-netdev&m=117305184005985&w=2)
However, nl80211 still isn't near any usable state. Worse yet, even
the API is nowhere near sufficient for replacing wext. So I was
wondering if anyone is working on this. (google pointed me to
pynl80211, hence Cc: Johannes)
As far as I understand, the first thing to tackle is converting
everything to cfg80211 and making wext call cfg80211 functions,
putting all the compatibility cruft into that layer while at it. This
could be done incrementally, step-by-step, couldn't it? Or is there
major restructuring planned? If not, I'd certainly like spending a bit
of work on this (my time is as limited as everyone's, but I do have
some wasted time here and there). However, a proper outline of the API
needs to be thought of first.
My very-humble totally-irrelevant opinion would be that nl80211 should
provide all neccessary operations, only much more cleanly than wext
;). So that means, at least a PHY configuration command (am I missing
something or is there none yet?) with attributes to specify channel &
co. The "set association" command might be extended to work for
interfaces. Proprietary/custom driver extensions could be handled as
special attributes and/or special commands. (that explicitly excludes
the PRISM2 cruft though, those are actually rather generic IMHO)
Anyway, I'm hoping to start a little constructive discussion and
planning here. Opinions?
-David Lamparter
P.S.: While I'm aware that changing kernel APIs is a very bad idea,
I'm really thinking nl80211 isn't frozen yet. As far as I can tell,
only iwspy and pynl80211 are using it at all. This hopefully won't end
up as a compatibility nightmare AGAIN?
Hooray, message crossing :)
> What I'd do if I had time now is add things to nl80211/cfg80211 and then
> implement the calls in mac80211 (or a fullmac driver of your choice.)
> Then write the appropriate userspace tool for testing and see if it
> works, i.e. you can associate, do key operations etc. Use WEP for now,
> and then maybe modify wpa_supplicant too for nl80211. Then, at some
> point, you have wpa_supplicant working on mac80211 (or the driver). Then
> in theory you don't need wext any more, and as an afterthought you can
> still add wext compatibility so the deprecated wireless tools continue
> to work.
Yeah, I agree. Guess I overshooted a bit on converting wext. For the
userspace part I started by adding some genetlink helper functions to
iproute2, will try to get them upstream later. (tomorrow)
I'm hoping to add an "ip wireless" part, since iproute2 already has all the
netlink stuff and I really like its syntax. I rudimentarily started hacking
it up, which is why I noticed there's no PHY configuration command.
For the kernel part, if I were to work on it, I'd be adding it to mac80211.
The only 802.11 devices I own are a laptop with a rt2500 and a WRT router,
and developing for that router isn't that fun.
David
---
[equinox@neptune]:~/src/iproute2/ip # ./ip w
0: phy0
RTNETLINK answers: Operation not supported
6: wlan0: association status unknown
RTNETLINK answers: Operation not supported
5: wmaster0: association status unknown
Hi Johannes,
> > As far as I understand, the first thing to tackle is converting
> > everything to cfg80211 and making wext call cfg80211 functions,
> > putting all the compatibility cruft into that layer while at it.
>
> I wouldn't necessarily start with that.
Hmm, true, converting wext isn't really needed first. Does making
cfg80211 usable make a better candidate for first work? As far as I can
tell, the only thing mac80211 implements for cfg80211 is interface
creation / deletion...
> > So that means, at least a PHY configuration command (am I missing
> > something or is there none yet?) with attributes to specify channel &
> > co.
>
> Oh, heh, that does indeed seem to be missing...
I'd propose two additional commands:
- NL80211_CMD_GET_WIPHY [_CFG]
- NL80211_CMD_SET_WIPHY [_CFG]
which would be invoked with a NL80211_ATTR_WIPHY and setting/getting
NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_CHANNEL and NL80211_ATTR_PHYMODE.
NL80211_CMD_RENAME_WIPHY could be dropped and replaced by
NL80211_CMD_SET_WIPHY. There seems to be no "get name" command yet,
so that will be covered too.
(actually NL80211_CMD_SET_WIPHY would be backwards compatible with
NL80211_RENAME_WIPHY since the latter is invoked with the same attributes)
The NEWNAME notify-command could be renamed and used for channel / phymode
notifications too.
> Not sure what you mean here. The NL80211_CMD_ASSOCIATE command as I see
> it is modeled after the 802.11 mlme interface, nl80211.h says:
>
> > * @NL80211_CMD_ASSOCIATE: associate with the given parameters
> > * (%NL80211_ATTR_SSID is mandatory, %NL80211_ATTR_TIMEOUT_TU,
> > * %NL80211_ATTR_BSSID, %NL80211_ATTR_CHANNEL, %NL80211_ATTR_PHYMODE,
> > * and %NL80211_ATTR_IE may be given)
>
> Hence, here we also have the ability to set the phy mode/channel. We
> still need an explicit command for that though for monitor interfaces.
Yes, thats what I meant for interface configuration. However, I don't
think NL80211_ATTR_CHANNEL and NL80211_ATTR_PHYMODE belong here - if
something is capable of using more than one channel, it really should
have more phys, not more interfaces...
> Do I look dead yet? No way. Proprietary/custom driver extensions live in
> debugfs. If you need something that's generally useful, we can add it to
> nl80211/cfg80211, otherwise you get to feel the pain of having it in
> debugfs.
Ah, I didn't think of that. Full ACK.
> Oh, I very much agree, nl80211 isn't frozen yet (except for that tiny
> part that's in mainline already). And all of nl80211 API are the numbers
> in the nl80211.h header file that userspace gets to see, so...
Phew. The only thing nl80211.h contains in mainline is enum nl80211_iftype.
So the possibility to make generic getter/setters out of the NAME commands
is still there...
David
(Stephan: sorry, forgot to Cc: you)
Hi David,
> together with a friend of mine, I recently pondered about making linux
> wireless configuration utilities more friendly to use. He did some
> hacking to add wext to iproute2, but got "use nl80211" as reply. (cf.
> http://marc.info/?l=linux-netdev&m=117305184005985&w=2)
Ah right, I remember that. Yeah, wext isn't really going anywhere.
> However, nl80211 still isn't near any usable state. Worse yet, even
> the API is nowhere near sufficient for replacing wext. So I was
> wondering if anyone is working on this. (google pointed me to
> pynl80211, hence Cc: Johannes)
This, unfortunately, is true. If you look at the wireless-dev version of
include/linux/nl80211.h that's what I planned right now and that should
(unless I forgot something) be sufficient to replace some more wext
things, but there are also things missing, notably event reporting.
However, there's also hardly any code to unwrap the netlink messages and
translate them to cfg80211 calls (what there is is all in
net/wireless/nl80211.c).
> As far as I understand, the first thing to tackle is converting
> everything to cfg80211 and making wext call cfg80211 functions,
> putting all the compatibility cruft into that layer while at it.
I wouldn't necessarily start with that.
> This
> could be done incrementally, step-by-step, couldn't it?
Yes, it could
> Or is there
> major restructuring planned? If not, I'd certainly like spending a bit
> of work on this (my time is as limited as everyone's, but I do have
> some wasted time here and there). However, a proper outline of the API
> needs to be thought of first.
The outline of what the nl80211 userspace API provides is in
include/linux/nl80211.h, the outline of what cfg80211 provides is in
include/net/cfg80211.h (both in wireless-dev, mainline contains *really*
stripped down versions)
> My very-humble totally-irrelevant opinion would be that nl80211 should
> provide all neccessary operations, only much more cleanly than wext
> ;).
That's the plan :)
> So that means, at least a PHY configuration command (am I missing
> something or is there none yet?) with attributes to specify channel &
> co.
Oh, heh, that does indeed seem to be missing...
> The "set association" command might be extended to work for
> interfaces.
Not sure what you mean here. The NL80211_CMD_ASSOCIATE command as I see
it is modeled after the 802.11 mlme interface, nl80211.h says:
> * @NL80211_CMD_ASSOCIATE: associate with the given parameters
> * (%NL80211_ATTR_SSID is mandatory, %NL80211_ATTR_TIMEOUT_TU,
> * %NL80211_ATTR_BSSID, %NL80211_ATTR_CHANNEL, %NL80211_ATTR_PHYMODE,
> * and %NL80211_ATTR_IE may be given)
Hence, here we also have the ability to set the phy mode/channel. We
still need an explicit command for that though for monitor interfaces.
> Proprietary/custom driver extensions could be handled as
> special attributes and/or special commands. (that explicitly excludes
> the PRISM2 cruft though, those are actually rather generic IMHO)
Do I look dead yet? No way. Proprietary/custom driver extensions live in
debugfs. If you need something that's generally useful, we can add it to
nl80211/cfg80211, otherwise you get to feel the pain of having it in
debugfs.
> P.S.: While I'm aware that changing kernel APIs is a very bad idea,
> I'm really thinking nl80211 isn't frozen yet. As far as I can tell,
> only iwspy and pynl80211 are using it at all. This hopefully won't end
> up as a compatibility nightmare AGAIN?
Oh, I very much agree, nl80211 isn't frozen yet (except for that tiny
part that's in mainline already). And all of nl80211 API are the numbers
in the nl80211.h header file that userspace gets to see, so...
johannes
On Tue, 2007-06-05 at 12:53 +0200, Johannes Berg wrote:
> > As far as I understand, the first thing to tackle is converting
> > everything to cfg80211 and making wext call cfg80211 functions,
> > putting all the compatibility cruft into that layer while at it.
>
> I wouldn't necessarily start with that.
I should've elaborated here.
What I'd do if I had time now is add things to nl80211/cfg80211 and then
implement the calls in mac80211 (or a fullmac driver of your choice.)
Then write the appropriate userspace tool for testing and see if it
works, i.e. you can associate, do key operations etc. Use WEP for now,
and then maybe modify wpa_supplicant too for nl80211. Then, at some
point, you have wpa_supplicant working on mac80211 (or the driver). Then
in theory you don't need wext any more, and as an afterthought you can
still add wext compatibility so the deprecated wireless tools continue
to work.
johannes
On Tue, 2007-06-05 at 16:09 +0200, David Lamparter wrote:
> Hooray, message crossing :)
Heh.
> Yeah, I agree. Guess I overshooted a bit on converting wext. For the
> userspace part I started by adding some genetlink helper functions to
> iproute2, will try to get them upstream later. (tomorrow)
libnl already has generic netlink stuff in its svn version.
> I'm hoping to add an "ip wireless" part, since iproute2 already has all the
> netlink stuff and I really like its syntax. I rudimentarily started hacking
> it up, which is why I noticed there's no PHY configuration command.
Nice. I'm not too keen on having it as "ip wireless" since it isn't
really much related to ip. But if you want to work on it and decide to
put it there I won't stop you :)
> For the kernel part, if I were to work on it, I'd be adding it to mac80211.
> The only 802.11 devices I own are a laptop with a rt2500 and a WRT router,
> and developing for that router isn't that fun.
Well rt2500 with mac80211 sounds good to me, only some fullmac chipsets
would be able to interface with cfg80211. Oh and that WRT router
probably either has an atheros (no useful linux drivers) or a broadcom
(bcm43xx/bcm43xx-mac80211) chipset.
johannes
Hi David,
> Hmm, true, converting wext isn't really needed first. Does making
> cfg80211 usable make a better candidate for first work?
Yeah, I think so.
> As far as I can
> tell, the only thing mac80211 implements for cfg80211 is interface
> creation / deletion...
Yes, that's true. But cfg80211 also doesn't implement that much more of
nl80211 right now.
> I'd propose two additional commands:
>
> - NL80211_CMD_GET_WIPHY [_CFG]
> - NL80211_CMD_SET_WIPHY [_CFG]
>
> which would be invoked with a NL80211_ATTR_WIPHY and setting/getting
> NL80211_ATTR_WIPHY_NAME, NL80211_ATTR_CHANNEL and NL80211_ATTR_PHYMODE.
Hmm, this does seem to be orthogonal, for example changing the channel
could be accepted but changing the name could fail. Hence, it doesn't
make sense to use all these attributes together. IMHO adding commands
isn't a problem, so I'd rather see RENAME_WIPHY stay while adding a
command to switch channels. Something like SET_CHANNEL(CHANNEL,PHYMODE).
> The NEWNAME notify-command could be renamed and used for channel / phymode
> notifications too.
Again, these two are orthogonal and I'd rather see them split.
> Yes, thats what I meant for interface configuration. However, I don't
> think NL80211_ATTR_CHANNEL and NL80211_ATTR_PHYMODE belong here - if
> something is capable of using more than one channel, it really should
> have more phys, not more interfaces...
I don't understand this comment. The CHANNEL/PHYMODE attributes are used
with associating as per the 802.11 mlme interface. Yes, if you support
multiple channels/PHYs then you should have multiple wiphys, but that
doesn't preclude allowing to set the channel/phymode in the same command
as changing the association, no?
> Phew. The only thing nl80211.h contains in mainline is enum nl80211_iftype.
> So the possibility to make generic getter/setters out of the NAME commands
> is still there...
Right, that was needed to get cfg80211/mac80211 with virtual interfaces
to compile.
johannes