wireless management... kernel or user space?
Subsystems (2)
With the various discussions going on about a generic 802.11 frame/management stack, and the recent thread on wireless extensions, I wanted to find out what people's thoughts are on where wireless management should occur -- kernel or user space...
Within the hostap project there exists the ability to have some AP management occur internal to the driver or (via the PRISM2_NO_KERNEL_IEEE80211_MGMT define) in a user space daemon.
Does anyone have any thoughts on how much logic should be placed into the generic 802.11 frame/management/control handling stack vs. pushing to a user space component?
If (for example) AP associate request / response policy is pushed to a user space component, by what mechanism does it make sense for the driver/application to send/receive the 802.11 frames? Are people happy with the way Host AP currently does it, or is there a better way?
Other types of policy that could occur in user space would be for scan requests, probe response collection, AP selection to associate, etc. What is the general direction the wireless networking stack should take? Minimize kernel side wherever possible?
With ipw2100 (and I believe other cards) the hw/fw handles a lot of the above internally, so the mechanism by which the user space application communicates with the driver would need allow for hw/fw capabilities to be exposed so the user doesn't get a broken experience.
Thoughts?
James
(of ipw2100.sf.net)
A message that is not in the archive (sent off-list or not yet received): [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 6 lines · Jouni Malinen
Quoted 3 lines
Does anyone have any thoughts on how much logic should be placed into the generic 802.11 frame/management/control handling stack vs. pushing to a user space component?
The ideal location of this logic implementation seems to depend a bit on what one is doing..
[skip]
I would add 2 points:
- - we should look carefully for timing requirements. For example, for association req/resp, there is no timing requirement in the standard at all; for auth sequence with WEP, there is maximum timeout between 2-nd and 3-rd frames, but it is not very strong. My point is, if there is flow that require timing under 10-20 ms (or even 50), it should be done in kernel.
- - there are lots of meta-information associated with self and wireless peers, related to rate scaling, QoS parameters, authentication details etc. I would say there is such entity, "peers data base". It may reside in either user space, or within the kernel. Logically, management entity and peers data base should be on the same side of kernel/user boundary. Rate scaling, if done on the host, is very time critical and should be done in kernel. This pushes me to the point that it should be in kernel.
BTW, .1X flow is pure data. It is not management one, in terms of 802.11.
Vladimir.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA1Swpqxdj7mhC6o0RAhH3AKCL5CBpytVRs65jl8HHCI2eSbasNACgo+vZ ta5MHMuyGgvqOtlt6LjiD+s=
=ZZIH
-----END PGP SIGNATURE-----