Hi Linville,
Here is a V2 patch series to cleanup the 11e/WMM code in wireless-dev
GIT head 3480b61c08559777c57b95e346507b26253ca8bb after reviewed by
Johannes Berg. Please apply.
[PATCH 1/6] mac80211: Add IEEE80211_ prefix to SET_TSINFO_{} macros
[PATCH 2/6] mac80211: Fix TSINFO macros endian issue
[PATCH 3/6] mac80211: fix typo in net/mac80211/ieee80211_sta.c
[PATCH 4/6] mac80211: remove global tsinfo debugfs variables
[PATCH 5/6] mac80211: Fix sparse error for the IEEE802.11e/WMM code
[PATCH 6/6] mac80211: Fix sparse error for sta_last_seq_ctrl_read
Thanks,
-yi
On Mon, 2007-06-18 at 10:41 +0200, Johannes Berg wrote:
> I can understand that. I guess I'm still dreaming of some sort of ideal
> world where NM and wpa_supplicant use nl80211 to communicate so that it
> is easier to use a different userspace MLME maybe, or maybe just have
> another program like 'iw' work together with the whole lot easily as
> well.
Actually, I should qualify: I don't care much if NM relies on
wpa_supplicant, but more if using wpa_supplicant makes using 'iw'
impossible, and thus everybody is required to use wpa_cli and hence
wpa_supplicant ultimately becomes the only choice.
johannes
On Thursday 14 June 2007 00:36, Johannes Berg wrote:
> For me, that settles the DLS API. That API is easily implementable by
> the userspace MLME as well.
>
This API is unnecessary. The most that is needed is a bit indicating whether
or not an sta_info entry is DLS or not.
-Michael Wu
On Mon, 2007-06-11 at 20:01 +0200, Johannes Berg wrote:
> Hi Yi,
>
> In sta_process_dls_req, you currently always accept DLS. I'm not sure
> how well power save mode works in mac80211 (probably not at all, someone
> versed in 802.11 should probably look at it some time soon), but once
> DLS is set up power saving must be disabled by the DLS peer. This,
> however, possibly leads to battery lifetime diminishing, so always
> accepting the direct link might not be desirable. Any thoughts?
You are right. I once had the debugfs file on the DLS request response
side to to indicate accept or deny all DLS requests. But after a second
thought, maybe a MAC list is better? But this is just for testing not a
real API.
> Should we have user-space controlled list of DLS possible DLS peers? Or
> call out to userspace via nl80211 to make a decision? The list would be
> easy by simply adding a sta_info for a possible DLS peer, callout also
> shouldn't be too hard by sending a message to some QoS nl80211 multicast
> group and possibly not responding to the DLS request at all when our
> userspace doesn't accept it (that way it'll just time out on the other
> side).
Right. For the real API, I'd prefer the kernel to send an event to
userspace (daemon) via netlink (nl80211) and let user space to make the
decision. This way mac80211 doesn't need to manage the user prefered DLS
list itself. Another benefit is the DLS connection could be established
interactively. For example when a user is VIing in Xwindows, a pop up
window from NetworkManager asks "MAC address XX:XX:.. wants to setup a
DLS connection with you, do you accept?"
Thanks,
-yi
On 6/12/07, Zhu Yi <[email protected]> wrote:
> On Tue, 2007-06-12 at 10:37 +0300, Tomas Winkler wrote:
> > This is correct that power save must be disabled explicitly in this
> > implementation. Usually you want to establish DLS for increasing
> > throughput so you won't go to power save mode anyway.
>
> Right.
>
> > One other thing is encryption, the path for peer key handshake must be
> > opened in mac80211 in addition to this patch.
>
> Authentication or encryption? I don't think either mac80211 or
> wpa_supplicant supports IBSS WPA/WPA2 currently, right. For WEP, it
> should work since both DLS peers use the same key as set in the AP.
>
Authentication is against AP in any case. In addition you have peer
key hand shake for exchanging encryption keys. It is similar to
EAPOL hand shake, need to keep port closed till the keys are
available. This should be supported in supplicant.
WEP is global to bss so there is no problem.
> Thanks,
> -yi
>
On Saturday 16 June 2007 05:27, Johannes Berg wrote:
> No, it's not unnecessary. In London, we said that we wanted the
> (userspace) MLME to be controllable via nl80211 from userspace.
I think that decision was made without much consideration to the
implementation details. I thought it was a good idea then, but passing
messages from userspace to the kernel and then to userspace again is really a
waste of time. NetworkManager already uses wpa_supplicant to avoid all the
nasty details of dealing with wireless configuration, so why not keep using
it for everything instead of hiding wpa_supplicant behind nl80211? This is
more simple and direct and allows the kernel to expose exactly what the
hardware/kernel can do. Userspace won't have to change much and nl80211 won't
have to support every possible thing a userspace MLME would want.
-Michael Wu
Hi Yi,
In sta_process_dls_req, you currently always accept DLS. I'm not sure
how well power save mode works in mac80211 (probably not at all, someone
versed in 802.11 should probably look at it some time soon), but once
DLS is set up power saving must be disabled by the DLS peer. This,
however, possibly leads to battery lifetime diminishing, so always
accepting the direct link might not be desirable. Any thoughts?
Should we have user-space controlled list of DLS possible DLS peers? Or
call out to userspace via nl80211 to make a decision? The list would be
easy by simply adding a sta_info for a possible DLS peer, callout also
shouldn't be too hard by sending a message to some QoS nl80211 multicast
group and possibly not responding to the DLS request at all when our
userspace doesn't accept it (that way it'll just time out on the other
side).
johannes
[if you haven't seen the rest of the thread skip down to the === mark]
On Sat, 2007-06-16 at 15:16 -0700, Michael Wu wrote:
> > I don't think the implementation details are much of a problem. It's
> > just a bit of message bouncing which is trivial. Except of course when
> > you consider wext, but hey, no need to consider that for this discussion
> > since you're proposing ditching wext completely. Not that I don't want
> > to ditch it, but people still use it and probably will. Heck, people
> > still use 'ifconfig'...
> >
> I'm not proposing to ditch wext completely. When did I say that?
You're saying that you want people to communicate directly with the
userspace MLME, so wext is out.
> It's a waste of time when nl80211 needs to be patched every time we want an
> additional command in the userspace MLME.
I actually see this as a benefit, that way the API gets some review...
Also, if you want to use a userspace library, that library will need
patching everytime you need an additional MLME command; if you don't
have any formal API then of course you don't have that problem but that
also means that all the applications aren't able to interoperate
properly.
It sounds to me like you're proposing that wpa_supplicant is the only
supported userspace MLME and that wpa_cli is the only way to configure
it, basically. I sure hope that isn't so.
> I don't think the needs of a firmware based MLME are necessarily the same as a
> userspace MLME. Some commands will certainly be the same, but just because
> the commands are there doesn't mean it's good to make them work if you have
> to fake it. The kernel should show what the hardware/stack can do and nothing
> more.
No, you don't understand. Of course something should tell you what your
wireless connection can do. But if there's a userspace MLME used to
implement that wireless connection then that userspace MLME tells you
what it can do, which is fine.
Saying that it's not good to make commands work is like saying every
tiny hardware difference should get new API to perfectly match that
particular hardware instead of using common API to work with all
hardware in a unified way.
That's the goal here anyway, to work with hardware in a unified way. And
hopefully there'll be more userspace MLMEs rather than just
wpa_supplicant. There's xsupplicant too, maybe it'll have some support,
who knows.
[===]
Yes, talking with the userspace MLME via netlink is some form of IPC. In
fact, I just had this idea that instead of having the kernel bounce
messages to the userspace MLME we could instead have a MLME-multicast
group. The kernel listens on that multicast group and executes the
commands if no other program is listening on the group, and the
configuration programs simply multicast the configuration requests.
We'll have to sort out in userspace that we never have two MLMEs running
at the same time, but that is far less effort than trying to sort out
finding the MLME in userspace. It also lets us control the API.
At the same time, however, this doesn't seem to be implementable using
generic netlink right now because we cannot allow non-root users to
listen on the MLME-multicast group (this isn't actually possible for
normal netlink either right now because we need non-root users listening
on other groups, but that could be easily solved with a patch to give a
non-root group mask instead of a flag for the netlink code)
However, digging through the code it seems that generic netlink is a bit
weird with multicast anyway. Right now, what you do as a userspace
application is you ask for multicast on the generic netlink socket, but
you can then talk to multiple families. As far as I can tell that means
that you'll be receiving multicasts for ACPI events and for nl80211
events if they happen to use the same groups. I'd think that generic
netlink should be integrated a bit better and it should be possible to
sign up for groups within a family.
When then it also becomes possible to disallow certain groups for
non-root users, we should be able to solve the userspace MLME problem by
using a multicast group as above, I haven't tested it yet though.
johannes
On Tue, 2007-06-12 at 16:06 +0800, Zhu Yi wrote:
> You are right. I once had the debugfs file on the DLS request response
> side to to indicate accept or deny all DLS requests. But after a second
> thought, maybe a MAC list is better? But this is just for testing not a
> real API.
Alright.
> Right. For the real API, I'd prefer the kernel to send an event to
> userspace (daemon) via netlink (nl80211) and let user space to make the
> decision. This way mac80211 doesn't need to manage the user prefered DLS
> list itself. Another benefit is the DLS connection could be established
> interactively. For example when a user is VIing in Xwindows, a pop up
> window from NetworkManager asks "MAC address XX:XX:.. wants to setup a
> DLS connection with you, do you accept?"
Yeah, I disagree with bothering the user with it, but the idea sounds
sane in that a userspace daemon is allowed to make the decision.
And putting it into the kernel now is actually a good thing, it forces
us to think about the use cases. When we stick it all into the userspace
MLME are we sure that the userspace MLME is the right place to make the
decision? I don't think it is, so we need the MLME API anyway.
johannes
On Tue, 2007-06-12 at 10:37 +0300, Tomas Winkler wrote:
> This is correct that power save must be disabled explicitly in this
> implementation. Usually you want to establish DLS for increasing
> throughput so you won't go to power save mode anyway.
Right.
> One other thing is encryption, the path for peer key handshake must be
> opened in mac80211 in addition to this patch.
Authentication or encryption? I don't think either mac80211 or
wpa_supplicant supports IBSS WPA/WPA2 currently, right. For WEP, it
should work since both DLS peers use the same key as set in the AP.
Thanks,
-yi
On Mon, 2007-06-18 at 10:08 +0800, Zhu Yi wrote:
> OK. This is the key of the discussion.
I agree.
> Do we take wpa_supplicant the
> only implementation of userspace MLME or even decision making (ie. DLS
> config) daemon?
I think it's a combination of these facts. I don't think DLS decision
making can properly live in wpa_supplicant, it'll need to be integrated
into various multimedia frameworks for example. What Michael is
basically proposing from what I can tell is that all these frameworks
rely on wpa_supplicant's socket-based configuration to tell
wpa_supplicant about it.
> If so, we don't need the API. Otherwise we'd better have
> the API in the kernel because we cannot expect both userspace MLME
> implentation A and B support the same API (via IPC) for configuration.
Exactly. On the one hand I guess you could argue that if the MLME
implementation would be in the kernel there'd only be one as well, but
on the other hand I'd rather be able to have various different MLMEs.
Maybe the xsupplicant project is interested in doing some of this as
well, or maybe some of the various wireless testing tools would like to
be an MLME too under some circumstances...
johannes
On Sun, 2007-06-17 at 14:03 +0200, Johannes Berg wrote:
> It sounds to me like you're proposing that wpa_supplicant is the only
> supported userspace MLME and that wpa_cli is the only way to configure
> it, basically. I sure hope that isn't so.
OK. This is the key of the discussion. Do we take wpa_supplicant the
only implementation of userspace MLME or even decision making (ie. DLS
config) daemon? If so, we don't need the API. Otherwise we'd better have
the API in the kernel because we cannot expect both userspace MLME
implentation A and B support the same API (via IPC) for configuration.
Thanks,
-yi
Alright, let me try to summarise what we want as API for DLS:
* NL80211_CMD_GET_DLS_PEER
doit: simple boolean answer: is DLS set up with given peer?
dump: give all DLS peers
* NL80211_CMD_SET_DLS_PEER [_CMD_REQUEST_DLS]
request setup of DLS
* NL80211_CMD_NEW_DLS_PEER
kernel notification about a newly setup DLS connection
* NL80211_CMD_DEL_DLS_PEER [_CMD_TEARDOWN_DLS]
request teardown of DLS connection
* NL80211_CMD_NEW_DLS_REQUEST
kernel notification for DLS request from the other side
* NL80211_CMD_SET_DLS_REQUEST
send DLS response to given peer with given status
(* NL80211_CMD_GET_DLS_REQUEST
* NL80211_CMD_DEL_DLS_REQUEST
make no sense)
I tried ordering these by get/set/new/del quads as David suggested but I
don't think it makes sense for DLS request, I suppose we have somewhat
different requirements and I think I'd rather have different names as in
brackets above. Then again, that could get confusing with
_CMD_REQUEST_DLS and _CMD_NEW_DLS_REQUEST...
For me, that settles the DLS API. That API is easily implementable by
the userspace MLME as well.
Now, for TS, it seems that most of the work is with handling the
response to an ADD TS request. Also, the current code doesn't seem to
allow using TCLAS or TCLAS processing information for the ADDTS request
frame. For the response, I suppose you'll be adding it, but I'm not sure
we want to have all the complexity for the request. Maybe we should
simply require the ADDTS/DELTS request frames to be injected and we
handle the responses with some notifications via nl80211?
johannes
On Thu, 2007-06-14 at 09:35 -0700, Michael Wu wrote:
> On Thursday 14 June 2007 00:36, Johannes Berg wrote:
> > For me, that settles the DLS API. That API is easily implementable by
> > the userspace MLME as well.
> >
> This API is unnecessary. The most that is needed is a bit indicating whether
> or not an sta_info entry is DLS or not.
No, it's not unnecessary. In London, we said that we wanted the
(userspace) MLME to be controllable via nl80211 from userspace. Hence,
we need API to do DLS setup/teardown because the (userspace) MLME is not
going to be the program making the decision about DLS and we explicitly
said that we want the MLME to be controllable via nl80211 no matter
where it lives.
johannes
On 6/11/07, Johannes Berg <[email protected]> wrote:
> Hi Yi,
>
> In sta_process_dls_req, you currently always accept DLS. I'm not sure
> how well power save mode works in mac80211 (probably not at all, someone
> versed in 802.11 should probably look at it some time soon), but once
> DLS is set up power saving must be disabled by the DLS peer. This,
> however, possibly leads to battery lifetime diminishing, so always
> accepting the direct link might not be desirable. Any thoughts?
>
This is correct that power save must be disabled explicitly in this
implementation. Usually you want to establish DLS for increasing
throughput so you won't go to power save mode anyway.
One other thing is encryption, the path for peer key handshake must be
opened in mac80211 in addition to this patch.
> Should we have user-space controlled list of DLS possible DLS peers? Or
> call out to userspace via nl80211 to make a decision? The list would be
> easy by simply adding a sta_info for a possible DLS peer, callout also
> shouldn't be too hard by sending a message to some QoS nl80211 multicast
> group and possibly not responding to the DLS request at all when our
> userspace doesn't accept it (that way it'll just time out on the other
> side).
>
> johannes
>
>
On Sat, 2007-06-16 at 11:29 -0700, Michael Wu wrote:
> I think that decision was made without much consideration to the
> implementation details.
I don't think the implementation details are much of a problem. It's
just a bit of message bouncing which is trivial. Except of course when
you consider wext, but hey, no need to consider that for this discussion
since you're proposing ditching wext completely. Not that I don't want
to ditch it, but people still use it and probably will. Heck, people
still use 'ifconfig'...
> I thought it was a good idea then, but passing
> messages from userspace to the kernel and then to userspace again is really a
> waste of time.
It's not happening a lot so it's not a waste of *much* time ;)
> NetworkManager already uses wpa_supplicant to avoid all the
> nasty details of dealing with wireless configuration, so why not keep using
> it for everything instead of hiding wpa_supplicant behind nl80211?
I hope that nm would start using nl80211 instead of talking to
wpa_supplicant and just start wpa_supplicant if necessary. Or maybe some
startup scripts start the userspace MLME (wpa_supplicant) for the
interfaces during boot/hotplug.
> This is
> more simple and direct and allows the kernel to expose exactly what the
> hardware/kernel can do. Userspace won't have to change much and nl80211 won't
> have to support every possible thing a userspace MLME would want.
It's not that the kernel will have to support everything that a
userspace MLME would want, but rather that the kernel needs to support
everything the MLME would want, to support fullmac drivers.
Another counter: when you have a tool like 'iw' that David wrote, then
it'll need to look for the userspace MLME every time you invoke it and
start communicating with it instead of the kernel. That's likely a waste
of much more time than just bouncing the messages.
johannes
On Sun, 2007-06-17 at 11:29 -0400, Dan Williams wrote:
> NM uses wpa_supplicant for 3 basic things:
<snip good explanation, thanks>
> I like pushing most of the config stuff to wpa_supplicant, because that
> basically means that all of that is in _one_ project. When
> nl80211/cfg80211 land and start getting adopted, that means that only
> _one_ of {NM, wpa_supplicant} needs to get ported over, instead of two.
I can understand that. I guess I'm still dreaming of some sort of ideal
world where NM and wpa_supplicant use nl80211 to communicate so that it
is easier to use a different userspace MLME maybe, or maybe just have
another program like 'iw' work together with the whole lot easily as
well.
johannes
On Sat, 2007-06-16 at 20:51 +0200, Johannes Berg wrote:
> On Sat, 2007-06-16 at 11:29 -0700, Michael Wu wrote:
>
> > I think that decision was made without much consideration to the
> > implementation details.
>
> I don't think the implementation details are much of a problem. It's
> just a bit of message bouncing which is trivial. Except of course when
> you consider wext, but hey, no need to consider that for this discussion
> since you're proposing ditching wext completely. Not that I don't want
> to ditch it, but people still use it and probably will. Heck, people
> still use 'ifconfig'...
>
> > I thought it was a good idea then, but passing
> > messages from userspace to the kernel and then to userspace again is really a
> > waste of time.
>
> It's not happening a lot so it's not a waste of *much* time ;)
>
> > NetworkManager already uses wpa_supplicant to avoid all the
> > nasty details of dealing with wireless configuration, so why not keep using
> > it for everything instead of hiding wpa_supplicant behind nl80211?
>
> I hope that nm would start using nl80211 instead of talking to
> wpa_supplicant and just start wpa_supplicant if necessary. Or maybe some
> startup scripts start the userspace MLME (wpa_supplicant) for the
> interfaces during boot/hotplug.
NM uses wpa_supplicant for 3 basic things:
1) configuration of an 802.11 connection
2) getting scan results
3) WPA/802.1x
wpa_supplicant doesn't separate the configuration/setup of an interface
from the 802.1x stuff, mainly because it has to do things like derive
keys and push them down to the driver at specific times. These two
functions are pretty intimately related. And since NM needs WPA
support, it uses wpa_supplicant for the 802.1x/WPA stuff. The only
stuff left is open & static WEP, which wpa_supplicant also handles. So
it was a no-brainer to push all the wireless config to wpa_supplicant
and have NM just feed wpa_supplicant the config info.
NM now gets its scan results from wpa_supplicant because drivers used to
get (and some still do) very confused when multiple processes would
request scans and get results. There was a nice race between
wpa_supplicant and NM in some drivers (airo in particular) where
wpa_supplicant would request a scan, and the driver would signal
results, but by the time NM saw the event and requested the results,
wpa_supplicant had already consumed them. This was "fixed" by making
drivers age scan results like ipw2x00 over a number of scans and not
erasing them right away after the scan was done.
I like pushing most of the config stuff to wpa_supplicant, because that
basically means that all of that is in _one_ project. When
nl80211/cfg80211 land and start getting adopted, that means that only
_one_ of {NM, wpa_supplicant} needs to get ported over, instead of two.
Dan
> > This is
> > more simple and direct and allows the kernel to expose exactly what the
> > hardware/kernel can do. Userspace won't have to change much and nl80211 won't
> > have to support every possible thing a userspace MLME would want.
>
> It's not that the kernel will have to support everything that a
> userspace MLME would want, but rather that the kernel needs to support
> everything the MLME would want, to support fullmac drivers.
>
> Another counter: when you have a tool like 'iw' that David wrote, then
> it'll need to look for the userspace MLME every time you invoke it and
> start communicating with it instead of the kernel. That's likely a waste
> of much more time than just bouncing the messages.
>
> johannes
On Saturday 16 June 2007 11:51, Johannes Berg wrote:
> On Sat, 2007-06-16 at 11:29 -0700, Michael Wu wrote:
> > I think that decision was made without much consideration to the
> > implementation details.
>
> I don't think the implementation details are much of a problem. It's
> just a bit of message bouncing which is trivial. Except of course when
> you consider wext, but hey, no need to consider that for this discussion
> since you're proposing ditching wext completely. Not that I don't want
> to ditch it, but people still use it and probably will. Heck, people
> still use 'ifconfig'...
>
I'm not proposing to ditch wext completely. When did I say that?
> > I thought it was a good idea then, but passing
> > messages from userspace to the kernel and then to userspace again is
> > really a waste of time.
>
> It's not happening a lot so it's not a waste of *much* time ;)
>
It's a waste of time when nl80211 needs to be patched every time we want an
additional command in the userspace MLME.
> > NetworkManager already uses wpa_supplicant to avoid all the
> > nasty details of dealing with wireless configuration, so why not keep
> > using it for everything instead of hiding wpa_supplicant behind nl80211?
>
> I hope that nm would start using nl80211 instead of talking to
> wpa_supplicant and just start wpa_supplicant if necessary. Or maybe some
> startup scripts start the userspace MLME (wpa_supplicant) for the
> interfaces during boot/hotplug.
>
I don't think switching NM to nl80211 is reasonable unless you find someone to
port all the legacy drivers to cfg80211 too.
> > This is
> > more simple and direct and allows the kernel to expose exactly what the
> > hardware/kernel can do. Userspace won't have to change much and nl80211
> > won't have to support every possible thing a userspace MLME would want.
>
> It's not that the kernel will have to support everything that a
> userspace MLME would want, but rather that the kernel needs to support
> everything the MLME would want, to support fullmac drivers.
>
I don't think the needs of a firmware based MLME are necessarily the same as a
userspace MLME. Some commands will certainly be the same, but just because
the commands are there doesn't mean it's good to make them work if you have
to fake it. The kernel should show what the hardware/stack can do and nothing
more.
> Another counter: when you have a tool like 'iw' that David wrote, then
> it'll need to look for the userspace MLME every time you invoke it and
> start communicating with it instead of the kernel. That's likely a waste
> of much more time than just bouncing the messages.
>
I think the difference is trivial. Using nl80211 for what is effectively IPC
seems very incorrect to me.
-Michael Wu