Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Thu, 2006-10-26 at 11:33 -0400, Dan Williams wrote: > The one blocker I can think of here is startup scripts on various > distributions. Most of those are shell, and they usually rely on > iwconfig quite heavily. Getting those converted to wpa_supplicant > wouldn't be a trivial amount of work, but it wouldn't be a ton either. But as I've said forever... I intend to leave WE working when we move to cfg80211. We can't rip out the old userspace API just like that. johannes signature.asc Description: This is a digitally signed message part
RE: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Thu, 2006-10-26 at 14:41 -0700, Simon Barber wrote: > Getting people to use wpa_supplicant almost exclusivly as the interface > for wireless will improve a lot of things. One thing that might help > here is to do some work on the wpa_cli - to make it easier for the > startup scripts to do what they need, and also to make the command > syntax easier for command line users to do what they need. But we'll still want something to change channels when in monitor mode etc, so it can't really be exclusive. Hence, we need another tool as well. johannes signature.asc Description: This is a digitally signed message part
RE: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
Getting people to use wpa_supplicant almost exclusivly as the interface for wireless will improve a lot of things. One thing that might help here is to do some work on the wpa_cli - to make it easier for the startup scripts to do what they need, and also to make the command syntax easier for command line users to do what they need. Simon -Original Message- From: Dan Williams [mailto:[EMAIL PROTECTED] Sent: Thursday, October 26, 2006 8:33 AM To: Luis R. Rodriguez Cc: Johannes Berg; Michael Wu; Simon Barber; David Kimdon; netdev@vger.kernel.org; Jiri Benc; John W. Linville; Jean Tourrilhes; Hong Liu; Jouni Malinen Subject: Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211 On Thu, 2006-10-26 at 11:04 -0400, Luis R. Rodriguez wrote: > On 10/26/06, Dan Williams <[EMAIL PROTECTED]> wrote: > > While wpa_supplicant is certainly the main client for stuff directly > > related to setting up a connection, there are quite a few other > > users of general WE calls to pull information out of the card, or to > > receive scan events. > > How about we just ditch iwconfig completely and move on to > wpa_supplicant/wpa_cli as our next userspace application with > nl80211/cg80211 as our new API for usersapce-->kernel communication? > As you point out, wpa_supplicant already does a lot for us -- and > several distributions already rely on it. Some work is required but I > think its worth it. If we do a complete move from WE to nl80211 it > would be transparent to the users too. The one blocker I can think of here is startup scripts on various distributions. Most of those are shell, and they usually rely on iwconfig quite heavily. Getting those converted to wpa_supplicant wouldn't be a trivial amount of work, but it wouldn't be a ton either. Dan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Thu, 2006-10-26 at 11:04 -0400, Luis R. Rodriguez wrote: > On 10/26/06, Dan Williams <[EMAIL PROTECTED]> wrote: > > While wpa_supplicant is certainly the main client for stuff directly > > related to setting up a connection, there are quite a few other users of > > general WE calls to pull information out of the card, or to receive scan > > events. > > How about we just ditch iwconfig completely and move on to > wpa_supplicant/wpa_cli as our next userspace application with > nl80211/cg80211 as our new API for usersapce-->kernel communication? > As you point out, wpa_supplicant already does a lot for us -- and > several distributions already rely on it. Some work is required but I > think its worth it. If we do a complete move from WE to nl80211 it > would be transparent to the users too. The one blocker I can think of here is startup scripts on various distributions. Most of those are shell, and they usually rely on iwconfig quite heavily. Getting those converted to wpa_supplicant wouldn't be a trivial amount of work, but it wouldn't be a ton either. Dan - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/26/06, Dan Williams <[EMAIL PROTECTED]> wrote: While wpa_supplicant is certainly the main client for stuff directly related to setting up a connection, there are quite a few other users of general WE calls to pull information out of the card, or to receive scan events. How about we just ditch iwconfig completely and move on to wpa_supplicant/wpa_cli as our next userspace application with nl80211/cg80211 as our new API for usersapce-->kernel communication? As you point out, wpa_supplicant already does a lot for us -- and several distributions already rely on it. Some work is required but I think its worth it. If we do a complete move from WE to nl80211 it would be transparent to the users too. Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Thu, 2006-10-26 at 10:35 -0400, Dan Williams wrote: > > - I'd like to see a header cleanup, it's necessary. Part of the problem > >here is all the sub-ioctl WE foo. Clean that up by moving them into > >cfg80211 as required, there's basically one user, wpa_supplicant (and > >maybe hostapd), screw the others if there are any Oh, right, by sub-ioctl I was referring to the mess of the private ioctls d80211 has for WE, including sub-items again. > While wpa_supplicant is certainly the main client for stuff directly > related to setting up a connection, there are quite a few other users of > general WE calls to pull information out of the card, or to receive scan > events. Of course. > So if you want maximum compatibility for a limited amount of > work, you can probably consider wpa_supplicant the only client of > > (s = set, g = get) > > 1) [s|g] ENCODEEXT > 2) [s|g] AUTH > 3) [s|g] MLME > 4) [s] RATE > 5) [s] FREQ > 6) [s] SENS > 7) [s] AP > 8) [s|g] RTS > 9) [s|g] FRAG > 10)[s|g] GENIE > 11)[s|g] PMKSA Sounds about right to me. I did actually intend to keep these intact but drop the private ones with the 10xx sub-numbers. > 4) [s|g] POWER (power management does this, not wpa_supplicant) Does it work for any card? johannes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Thu, 2006-10-26 at 00:00 +0200, Johannes Berg wrote: > On Wed, 2006-10-25 at 13:43 -0400, Luis R. Rodriguez wrote: > > > I guess my hope was that d80211 would just be more than a softmac > > implementation. When I hear wireless stack I don't think "softmac > > implementation", I think a robust set of headers and device > > definitions which all wireless devices can share. > > Not just that, a bunch of library functions for example for crypto would > be nice too. That's part of why I've been proposing that the tkip stuff > be library functions that the drivers can call if required, instead of > the bitfields. > > Currently, there's lot of top-down stuff in d80211, it does things which > depend on flags and then instructs the driver to do something. This is > good for a bunch of things, but in some cases where devices vary wildly > it may be better to go for library functions instead. IMHO the TKIP key > computation is such a case, it's trivial for a driver to call phase1 and > phase2 when required. > > > Also I thought we'd ditch WE as it seems we keep fixing it with gum > > (as seen by Linville's latest ABI compatibility fix). > > Well, that was sort of necessary. > > > If that wasn't > > the case then I'm suggesting it -- can we consider ditching WE? > > Well, no. We can make it a second-class citizen like I did with the > cfg80211 work where I made it just one userspace interface for cfg80211 > which admittedly sometimes strange behaviour, but it's still there and > current operations should still work with it (and I'd consider not > working a bug except if userspace never calls 'commit' and expects > things to work) > > > I'd say lets just go for a > > userspace MLME as its already written but I seriously think we need to > > ditch replace WE first. > > It seems no one has a plan on what to do though. > > - Jiri's trying to fix the SMP issues. That's great. > - Jiri also would like to expand ieee80211_conf.c, the stuff I >started for cfg80211 > - I'd like to see a header cleanup, it's necessary. Part of the problem >here is all the sub-ioctl WE foo. Clean that up by moving them into >cfg80211 as required, there's basically one user, wpa_supplicant (and >maybe hostapd), screw the others if there are any While wpa_supplicant is certainly the main client for stuff directly related to setting up a connection, there are quite a few other users of general WE calls to pull information out of the card, or to receive scan events. So if you want maximum compatibility for a limited amount of work, you can probably consider wpa_supplicant the only client of (s = set, g = get) 1) [s|g] ENCODEEXT 2) [s|g] AUTH 3) [s|g] MLME 4) [s] RATE 5) [s] FREQ 6) [s] SENS 7) [s] AP 8) [s|g] RTS 9) [s|g] FRAG 10)[s|g] GENIE 11)[s|g] PMKSA Notable exceptions: 1) [s|g] ENCODE 2) [s|g] MODE (other stuff turns on promiscuous mode) 3) [s|g] SCAN (other stuff needs to do this too) 4) [s|g] POWER (power management does this, not wpa_supplicant) Of course lots of stuff needs to get RATE, ESSID, AP, FREQ, etc. Dan > - fix people's minds to not expect a perfect solution immediately but >accept something that can be expanded on later. I think we need to >accept some breakage in our development trees to get anywhere at all. > > Actually, the last point should be first. > > Enough rant from me for today, > johannes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Wed, 2006-10-25 at 13:43 -0400, Luis R. Rodriguez wrote: > I guess my hope was that d80211 would just be more than a softmac > implementation. When I hear wireless stack I don't think "softmac > implementation", I think a robust set of headers and device > definitions which all wireless devices can share. Not just that, a bunch of library functions for example for crypto would be nice too. That's part of why I've been proposing that the tkip stuff be library functions that the drivers can call if required, instead of the bitfields. Currently, there's lot of top-down stuff in d80211, it does things which depend on flags and then instructs the driver to do something. This is good for a bunch of things, but in some cases where devices vary wildly it may be better to go for library functions instead. IMHO the TKIP key computation is such a case, it's trivial for a driver to call phase1 and phase2 when required. > Also I thought we'd ditch WE as it seems we keep fixing it with gum > (as seen by Linville's latest ABI compatibility fix). Well, that was sort of necessary. > If that wasn't > the case then I'm suggesting it -- can we consider ditching WE? Well, no. We can make it a second-class citizen like I did with the cfg80211 work where I made it just one userspace interface for cfg80211 which admittedly sometimes strange behaviour, but it's still there and current operations should still work with it (and I'd consider not working a bug except if userspace never calls 'commit' and expects things to work) > I'd say lets just go for a > userspace MLME as its already written but I seriously think we need to > ditch replace WE first. It seems no one has a plan on what to do though. - Jiri's trying to fix the SMP issues. That's great. - Jiri also would like to expand ieee80211_conf.c, the stuff I started for cfg80211 - I'd like to see a header cleanup, it's necessary. Part of the problem here is all the sub-ioctl WE foo. Clean that up by moving them into cfg80211 as required, there's basically one user, wpa_supplicant (and maybe hostapd), screw the others if there are any - fix people's minds to not expect a perfect solution immediately but accept something that can be expanded on later. I think we need to accept some breakage in our development trees to get anywhere at all. Actually, the last point should be first. Enough rant from me for today, johannes signature.asc Description: This is a digitally signed message part
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/24/06, Michael Wu <[EMAIL PROTECTED]> wrote: On Tuesday 24 October 2006 18:03, Luis R. Rodriguez wrote: > 1. Anyone working on completing FullMAC support on d80211? That doesn't really make sense. Fullmac devices should just use WE or cfg80211 because they, for the most part, do what d80211 does in firmware. There are also strange hybrid devices like ipw2100/ipw2200, but IMHO, it's not worth trying to bolt d80211 onto those devices unless saner firmware becomes available. I guess my hope was that d80211 would just be more than a softmac implementation. When I hear wireless stack I don't think "softmac implementation", I think a robust set of headers and device definitions which all wireless devices can share. Also I thought we'd ditch WE as it seems we keep fixing it with gum (as seen by Linville's latest ABI compatibility fix). If that wasn't the case then I'm suggesting it -- can we consider ditching WE? I appologize to get seriously off-topic here BTW but think I need to say this. I mean -- we can keep on advancing WE but I really don't want to deal with any more sub-ioctl hacks. I think its beeg good for us but I think we're hitting the limit of its capabilities. Madwifi is an example of a driver which has been breeded to live in the extremes of WE -- you can't pack any more brand new ioctls there. Sub-ioctls were just that -- a hack. Let's stop this and look for a better solution. How about jumping on Johannes Berg's nl80211/cfg80211 and providing a new user API through that? > 2. Who's working on a userspace MLME replacement for d80211 and where > are we with that? I think HostAP can handle authentication/association.. or was it wpa-supplicant? Maybe both.. As confirmed by Simon, wpa_supplicant. OK great. > 3. Who's doing the endianness/smp testing of d80211 and how far are we > with that? The endianness issues seemed fine the last time I checked, and people do seem to be testing BE enough that to uncover an endianness regression I introduced when converting WEP code to use crypto api. As for SMP/locking, I think Jiri Benc knows how to deal with this. Jiri --- how is that coming along? :) > > Lastly, as I have said in previous e-mails -- I agree with a userspace > daemon but where is it and how long before its ready.. also it may be > difficult to introduce as a requirement for distributions and for this > reason I am suggesting going with in-kernel regulatory domain control > and now perhaps in-kernel MLME for a first stable push of d80211, > specially since only... 3 in-kernel drivers currently use d80211! > 4 once p54 is merged, and more to come as I get to them. /me pokes Linville. and zd1211rw too, now that I'm done with sending RFC for regdomains work. If I don't have time I'll pass what I have to you. I think time working on the in-kernel MLME is well worth it since I would like softmac drivers to have feature parity with fullmac drivers. Anything beyond that can go to userspace as far as I'm concerned. (so transitioning to d80211 based drivers won't involve too much pain unless you really want to take advantage of new features) Not having in-kernel MLME does not necessarily mean having a disparity between SoftMAC and FullMAC. To me its more of a speed issue and a requirement of having a userspace daemons before using a SoftMAC wireless device. I can see distributions having issues with the requirement of a new userspace daemon in order to use wireless SoftMAC devices and would argue that if we can complete the in-kernel MLME that perhaps we should do this for the introduction of d80211 to stable and later on move it to userspace. I'd say lets just go for a userspace MLME as its already written but I seriously think we need to ditch replace WE first. Having some basic regulatory domain control in d80211 in the kernel should be okay for now just to make sure all drivers like the api presented. Working out the details of how to move the d80211 side stuff to userspace should be orthogonal to the driver interface and can be dealt with later, IMHO. That is only true if we stick with WE. Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/25/06, Jiri Benc <[EMAIL PROTECTED]> wrote: On Tue, 24 Oct 2006 13:41:12 -0400, Luis R. Rodriguez wrote: > Sure -- we can have on the ieee80211_conf struct an array of all > regulatory domains stack values that the device supports > (REGDOMAIN_FCC or 0x10 for FCC for example) if the developer agrees > the device has been certified to match the regulatory domain > restrictions as the stack defines it. I believe most modern devices > adhere to the PtMP restrictions pretty loosely and the magic is left > to the driver when the device is being certified so ultimately I see > devices sharing regulatory domains restrictions rather than defining > their own though. I'd consider defining your own device-specific > regulatory domain would be more of an exception we'd have to deal with > but that remains to be seen yet huh. It sounds overcomplicated to me. I'd rather like to see something like this: 1. As part of the initialization of the hardware, the driver detects that the device is certified for (say) channels 2 to 10 (that's not a real-life example, fortunately :-)). BTW we should also record the max Intentional Radiator (IR) power and define the default antenna gain then. That way the max IR to be used can be restricted by regdomain max EIRP - antenna gain. Currently d80211.h ieee80211_conf has a u8 power_level and u8 antenna_max. I assume antenna_max here is max antenna gain, but is power_level max IR or max computed EIRP? If its max IR then great. 2. The driver reports this somewhere (softmac drivers would report this to the stack). The the ieee80211_conf struct should work. 3. Based on outside conditions (userspace - or something - tells us about actual regdomain), the stack (or whatever) calls the driver and passes allowed channels etc. to it (if the driver wants that information). There is already previously reported driver's limitation taken in the account in that information. BTW this was what I intended for phase I for ieee80211_regdomain on d80211. Currently d80211 drivers define their channels as an array. After we cleared how we'd integrate it into the stack I then wanted to write a get_reg_channels(dev) and we'd use the device's mode and stack regdomain to give the driver back all valid channels for the stack's current regdomain. 4. If the outside conditions change (802.11d or user emigrates or something) that callback is called again with a new data. Through this approach the question then becomes do we inspect the device's saved limitations and compare to available regulatory domains and (a) based on that comparison select only a few regulatory domains that the device supports, or (b) do we do allow the device to jump to any regulatory domain and later do the proper validation? I think (a) is the way to go and is similar to what I suggested in the quoted text above but is more of a dynamic autoselection of supported regultory domains vs the driver-writer-lists-supported-regdomains approach. This is overcomplicated but AFAICT no other wireless stack has taken a good stab at assuring devices comply to regdomains centrally through a wireless stack. The problem is that dealing with all wireless devices and coming up with a way to assure all do comply to regulatory domains in a meaninful logical way without regard to where the MLME is implemented is slightly overcomplicated. I.e.: - I see no point in building a list of regdomains suported by the hardware. Point taken -- the regulatory domain should just mask the device's capabilities based on locale. - It's pretty common that the device has some limitation stated in the EPROM and the stack/something should deal with it in a way that is easy to use in a driver. ACK Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Tue, 24 Oct 2006 13:41:12 -0400, Luis R. Rodriguez wrote: > Sure -- we can have on the ieee80211_conf struct an array of all > regulatory domains stack values that the device supports > (REGDOMAIN_FCC or 0x10 for FCC for example) if the developer agrees > the device has been certified to match the regulatory domain > restrictions as the stack defines it. I believe most modern devices > adhere to the PtMP restrictions pretty loosely and the magic is left > to the driver when the device is being certified so ultimately I see > devices sharing regulatory domains restrictions rather than defining > their own though. I'd consider defining your own device-specific > regulatory domain would be more of an exception we'd have to deal with > but that remains to be seen yet huh. It sounds overcomplicated to me. I'd rather like to see something like this: 1. As part of the initialization of the hardware, the driver detects that the device is certified for (say) channels 2 to 10 (that's not a real-life example, fortunately :-)). 2. The driver reports this somewhere (softmac drivers would report this to the stack). 3. Based on outside conditions (userspace - or something - tells us about actual regdomain), the stack (or whatever) calls the driver and passes allowed channels etc. to it (if the driver wants that information). There is already previously reported driver's limitation taken in the account in that information. 4. If the outside conditions change (802.11d or user emigrates or something) that callback is called again with a new data. I.e.: - I see no point in building a list of regdomains suported by the hardware. - It's pretty common that the device has some limitation stated in the EPROM and the stack/something should deal with it in a way that is easy to use in a driver. Thanks, Jiri -- Jiri Benc SUSE Labs - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Tue, 2006-10-24 at 15:56 -0700, Simon Barber wrote: > Hi Luis, > > The CVS version of wpa_supplicant implements a user space Client MLME. > > Are there any FullMAC clients that do not also do regulatory in the > hardware? (Intel 2100/2200?) Atmel (atmel.c) has in-driver regulatory domain logic, though it uses a firmware default domain. But that can be overridden by the user, and it appears as if the firmware just accepts it. Orinoco, Airo, Prism54 (fullmac) all have a channel list in the driver for validation, though the firmware on both appears to enforce regulatory domains and the drivers return errors or the firmware refuses to associate when given channels outside the current regulatory domain. In short, it would be nice to have a common table of regulatory domain information (at least channel #s, frequency #s, and regulatory domain lookup tables) somewhere in the ieee80211 stack where even fullmac drivers could get to it, if just to reduce code duplication. Dan > > Simon > > > -Original Message- > From: Luis R. Rodriguez [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 24, 2006 3:03 PM > To: Simon Barber > Cc: David Kimdon; netdev@vger.kernel.org; Jiri Benc; John W. Linville; > Jean Tourrilhes > Subject: Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211 > > On 10/24/06, Simon Barber <[EMAIL PROTECTED]> wrote: > > The Client MLME code in the kernel was only ever written to be used > > for quick testing. It does not have good roaming performance, and was > > never intended to be a complete client. The right place for the Client > > > MLME is in userspace, where it can be closely coupled with the > > supplicant, and better scanning and roaming decisions can be made. If > > the Client MLME is removed from the kernel, then a userspace part is > > always required in order for 802.11 to be used at all. (It's already > > required in order to use any of the recent security modes, or have > > automatic network selection, or decent roaming). In this case the > > regulatory constraints can be set in a privileged userspace deamon. > > We also have to take into consideration FullMAC devices where we don't > need an MLME implemented in kernel/userspace and how regulatory domain > control will dictate their behaviour. My approach here was to support a > map between stack regulatory domain values and device regulatory domain > values. This is currently provided by ieee80211_regdomains. We can add > to ieee80211_conf a ieee80211_regulatory_map and if defined > d80211 will simply call the the stack's set regdomain which the device > implements and sets the regdomain internally to whatever the device > should have. > > Mind you I realize most new devices are taking the SoftMAC design > approach and while these vary ultimately I do agree with your point. > > All that said though: > > 1. Anyone working on completing FullMAC support on d80211? > 2. Who's working on a userspace MLME replacement for d80211 and where > are we with that? > 3. Who's doing the endianness/smp testing of d80211 and how far are we > with that? > > Lastly, as I have said in previous e-mails -- I agree with a userspace > daemon but where is it and how long before its ready.. also it may be > difficult to introduce as a requirement for distributions and for this > reason I am suggesting going with in-kernel regulatory domain control > and now perhaps in-kernel MLME for a first stable push of d80211, > specially since only... 3 in-kernel drivers currently use d80211! > > Luis > - > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
Hi Luis, The CVS version of wpa_supplicant implements a user space Client MLME. Are there any FullMAC clients that do not also do regulatory in the hardware? (Intel 2100/2200?) Simon -Original Message- From: Luis R. Rodriguez [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 24, 2006 3:03 PM To: Simon Barber Cc: David Kimdon; netdev@vger.kernel.org; Jiri Benc; John W. Linville; Jean Tourrilhes Subject: Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211 On 10/24/06, Simon Barber <[EMAIL PROTECTED]> wrote: > The Client MLME code in the kernel was only ever written to be used > for quick testing. It does not have good roaming performance, and was > never intended to be a complete client. The right place for the Client > MLME is in userspace, where it can be closely coupled with the > supplicant, and better scanning and roaming decisions can be made. If > the Client MLME is removed from the kernel, then a userspace part is > always required in order for 802.11 to be used at all. (It's already > required in order to use any of the recent security modes, or have > automatic network selection, or decent roaming). In this case the > regulatory constraints can be set in a privileged userspace deamon. We also have to take into consideration FullMAC devices where we don't need an MLME implemented in kernel/userspace and how regulatory domain control will dictate their behaviour. My approach here was to support a map between stack regulatory domain values and device regulatory domain values. This is currently provided by ieee80211_regdomains. We can add to ieee80211_conf a ieee80211_regulatory_map and if defined d80211 will simply call the the stack's set regdomain which the device implements and sets the regdomain internally to whatever the device should have. Mind you I realize most new devices are taking the SoftMAC design approach and while these vary ultimately I do agree with your point. All that said though: 1. Anyone working on completing FullMAC support on d80211? 2. Who's working on a userspace MLME replacement for d80211 and where are we with that? 3. Who's doing the endianness/smp testing of d80211 and how far are we with that? Lastly, as I have said in previous e-mails -- I agree with a userspace daemon but where is it and how long before its ready.. also it may be difficult to introduce as a requirement for distributions and for this reason I am suggesting going with in-kernel regulatory domain control and now perhaps in-kernel MLME for a first stable push of d80211, specially since only... 3 in-kernel drivers currently use d80211! Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Tuesday 24 October 2006 18:03, Luis R. Rodriguez wrote: > 1. Anyone working on completing FullMAC support on d80211? That doesn't really make sense. Fullmac devices should just use WE or cfg80211 because they, for the most part, do what d80211 does in firmware. There are also strange hybrid devices like ipw2100/ipw2200, but IMHO, it's not worth trying to bolt d80211 onto those devices unless saner firmware becomes available. > 2. Who's working on a userspace MLME replacement for d80211 and where > are we with that? I think HostAP can handle authentication/association.. or was it wpa-supplicant? Maybe both.. > 3. Who's doing the endianness/smp testing of d80211 and how far are we > with that? The endianness issues seemed fine the last time I checked, and people do seem to be testing BE enough that to uncover an endianness regression I introduced when converting WEP code to use crypto api. As for SMP/locking, I think Jiri Benc knows how to deal with this. > > Lastly, as I have said in previous e-mails -- I agree with a userspace > daemon but where is it and how long before its ready.. also it may be > difficult to introduce as a requirement for distributions and for this > reason I am suggesting going with in-kernel regulatory domain control > and now perhaps in-kernel MLME for a first stable push of d80211, > specially since only... 3 in-kernel drivers currently use d80211! > 4 once p54 is merged, and more to come as I get to them. /me pokes Linville. I think time working on the in-kernel MLME is well worth it since I would like softmac drivers to have feature parity with fullmac drivers. Anything beyond that can go to userspace as far as I'm concerned. (so transitioning to d80211 based drivers won't involve too much pain unless you really want to take advantage of new features) Having some basic regulatory domain control in d80211 in the kernel should be okay for now just to make sure all drivers like the api presented. Working out the details of how to move the d80211 side stuff to userspace should be orthogonal to the driver interface and can be dealt with later, IMHO. -Michael Wu pgpWGSngKV0AL.pgp Description: PGP signature
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/24/06, Simon Barber <[EMAIL PROTECTED]> wrote: The Client MLME code in the kernel was only ever written to be used for quick testing. It does not have good roaming performance, and was never intended to be a complete client. The right place for the Client MLME is in userspace, where it can be closely coupled with the supplicant, and better scanning and roaming decisions can be made. If the Client MLME is removed from the kernel, then a userspace part is always required in order for 802.11 to be used at all. (It's already required in order to use any of the recent security modes, or have automatic network selection, or decent roaming). In this case the regulatory constraints can be set in a privileged userspace deamon. We also have to take into consideration FullMAC devices where we don't need an MLME implemented in kernel/userspace and how regulatory domain control will dictate their behaviour. My approach here was to support a map between stack regulatory domain values and device regulatory domain values. This is currently provided by ieee80211_regdomains. We can add to ieee80211_conf a ieee80211_regulatory_map and if defined d80211 will simply call the the stack's set regdomain which the device implements and sets the regdomain internally to whatever the device should have. Mind you I realize most new devices are taking the SoftMAC design approach and while these vary ultimately I do agree with your point. All that said though: 1. Anyone working on completing FullMAC support on d80211? 2. Who's working on a userspace MLME replacement for d80211 and where are we with that? 3. Who's doing the endianness/smp testing of d80211 and how far are we with that? Lastly, as I have said in previous e-mails -- I agree with a userspace daemon but where is it and how long before its ready.. also it may be difficult to introduce as a requirement for distributions and for this reason I am suggesting going with in-kernel regulatory domain control and now perhaps in-kernel MLME for a first stable push of d80211, specially since only... 3 in-kernel drivers currently use d80211! Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
The Client MLME code in the kernel was only ever written to be used for quick testing. It does not have good roaming performance, and was never intended to be a complete client. The right place for the Client MLME is in userspace, where it can be closely coupled with the supplicant, and better scanning and roaming decisions can be made. If the Client MLME is removed from the kernel, then a userspace part is always required in order for 802.11 to be used at all. (It's already required in order to use any of the recent security modes, or have automatic network selection, or decent roaming). In this case the regulatory constraints can be set in a privileged userspace deamon. Simon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Kimdon Sent: Tuesday, October 24, 2006 7:02 AM To: Luis R. Rodriguez Cc: netdev@vger.kernel.org; Jiri Benc; John W. Linville; Jean Tourrilhes Subject: Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211 Hi, > The following patches extend 802.11 regulatory domain support of the > d80211 wireless stack through two modules: > > 1. ieee80211_regdomains > 2. iso3166-1 I am glad to see this work, this is something that we need a solution for. I do wonder if we can push most of this out of the kernel and into userspace. We could hard code a single set of constraints in the kernel which may be used world wide (802.11b channels 1-11, is that allowed everywhere?). Then we have a userspace tool which passes updated regulatory information into the kernel based on the user's country input. -David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/24/06, David Kimdon <[EMAIL PROTECTED]> wrote: Hi, > The following patches extend 802.11 regulatory domain support of the > d80211 wireless stack through two modules: > > 1. ieee80211_regdomains > 2. iso3166-1 I am glad to see this work, this is something that we need a solution for. I do wonder if we can push most of this out of the kernel and into userspace. We could hard code a single set of constraints in the kernel which may be used world wide (802.11b channels 1-11, is that allowed everywhere?). Unforunatley there is no easy middle ground that will make everyone happy. What I defined as World is there just as most devices seem to have such regulatory domain and what I defined it as is a compromise in what seems to be the middle of all restrictions. There is no easy answer here but I think the best is to consider that there is just no "World" regulatory domain unless all regulatory domain agencies do come up with one. We should see if legal can work with a few regulatory agencies to see if at least a few will agree on one... Then we have a userspace tool which passes updated regulatory information into the kernel based on the user's country input. Please see my more thorough reply to Johannes as he asked this first. But yes -- you are right. The main reason why this has been put in the kernel was to make a userspace daemon optional as it would allow us to easily introduce regulatory domain control without forcing distributions to use a new daemon immediately. Also we need to iron out userspace communication before even considering a userspace regulatory daemon. Keep in mind the Kconfig makes the regulatory domains defined optional except World compliant regulatory domain already. Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/24/06, John W. Linville <[EMAIL PROTECTED]> wrote: On Tue, Oct 24, 2006 at 01:33:32AM -0400, Luis R. Rodriguez wrote: > On 10/23/06, Johannes Berg <[EMAIL PROTECTED]> wrote: > >On Mon, 2006-10-23 at 18:41 -0400, Luis R. Rodriguez wrote: > > > >> The current setup on d80211.h makes regulatory domains device > >> specific. I believe this should be changed to be stack-specific -- > >> that is, all drivers adhere to the restrictions set by the stack's > >> current regulatory domain. > > > >There should be a way to have a certain device restrict that even > >further, if the driver wants to allow operation only in a domain that > >the device has been certified for (because it may malfunction otherwise, > >for example). > > Sure good idea -- we can provide a device specific regulatory domain > if necessary. We can easily introduce a device_regdomains linked list > on the ieee80211_conf which if not empty the driver will use it, else > the stack regdomain is used. The ieee80211_regdomains module already > provides the interfaces for the manipulation of such list. Pretty easy > fix, fortunately. It might be nice if this could be a "logical AND" operation? So if the device was certified for X, Y, and Z and the current domain allows V, W, and X then only X would be allowed. Perhaps it is too complicated to be worthwhile, but it seems doable and would be a nice flexibility. Sure -- we can have on the ieee80211_conf struct an array of all regulatory domains stack values that the device supports (REGDOMAIN_FCC or 0x10 for FCC for example) if the developer agrees the device has been certified to match the regulatory domain restrictions as the stack defines it. I believe most modern devices adhere to the PtMP restrictions pretty loosely and the magic is left to the driver when the device is being certified so ultimately I see devices sharing regulatory domains restrictions rather than defining their own though. I'd consider defining your own device-specific regulatory domain would be more of an exception we'd have to deal with but that remains to be seen yet huh. Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/24/06, Johannes Berg <[EMAIL PROTECTED]> wrote: Alright, here's more now that I can think clearly again :) > ISO 3166-1, as part of the ISO 3166 standard, provides codes for the names > of countries and dependent areas. It was first published in 1974 by > the International Organization for Standardization (ISO) and defines three > different codes for each area: > > * ISO 3166-1 alpha-2, a two-letter system with many applications, > most notably the Internet top-level domains (ccTLD) for countries. > * ISO 3166-1 alpha-3, a three-letter system. > * ISO 3166-1 numeric, a three-digit numerical system, which is > identical to that defined by the United Nations Statistical Division. > > Although this would usually be only used in userspace IEEE-802.11d > has made use of ISO-3166-1 alpha 3. This mapping was added > to enhance stack support for IEEE-802.11d and 802.11 Regulatory > Domain control. ieee80211_regdomains makes use of this module > by creating a map of iso3166 alpha3 country code to stack > regulatory domain. But if 802.11d only requires alpha 3, why put all the other stuff into the kernel as well? It would have been a half ass job for kernel iso3166-1 support, also though -- I feel we should leave this as-is until we have an ironed out userspace regulatory daemon. This would make regulatory domain/802.11d/MLME daemon optional to introduce for distributions until that part is done and distributions have happily adopted something. Since its a complete iso3166-1 db I wondered if any other modules would make use of it. An example of a similar db in the kernel is for Native Language Support (NLS) for filesystems. If no modules can make use of it the quicker this should be removed once we have a userspace API ready. CC'ing LKML to see if any other module can make use of this. Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
Hi, > The following patches extend 802.11 regulatory domain support of the > d80211 wireless stack through two modules: > > 1. ieee80211_regdomains > 2. iso3166-1 I am glad to see this work, this is something that we need a solution for. I do wonder if we can push most of this out of the kernel and into userspace. We could hard code a single set of constraints in the kernel which may be used world wide (802.11b channels 1-11, is that allowed everywhere?). Then we have a userspace tool which passes updated regulatory information into the kernel based on the user's country input. -David - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Tue, Oct 24, 2006 at 01:33:32AM -0400, Luis R. Rodriguez wrote: > On 10/23/06, Johannes Berg <[EMAIL PROTECTED]> wrote: > >On Mon, 2006-10-23 at 18:41 -0400, Luis R. Rodriguez wrote: > > > >> The current setup on d80211.h makes regulatory domains device > >> specific. I believe this should be changed to be stack-specific -- > >> that is, all drivers adhere to the restrictions set by the stack's > >> current regulatory domain. > > > >There should be a way to have a certain device restrict that even > >further, if the driver wants to allow operation only in a domain that > >the device has been certified for (because it may malfunction otherwise, > >for example). > > Sure good idea -- we can provide a device specific regulatory domain > if necessary. We can easily introduce a device_regdomains linked list > on the ieee80211_conf which if not empty the driver will use it, else > the stack regdomain is used. The ieee80211_regdomains module already > provides the interfaces for the manipulation of such list. Pretty easy > fix, fortunately. It might be nice if this could be a "logical AND" operation? So if the device was certified for X, Y, and Z and the current domain allows V, W, and X then only X would be allowed. Perhaps it is too complicated to be worthwhile, but it seems doable and would be a nice flexibility. John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
Alright, here's more now that I can think clearly again :) > ISO 3166-1, as part of the ISO 3166 standard, provides codes for the names > of countries and dependent areas. It was first published in 1974 by > the International Organization for Standardization (ISO) and defines three > different codes for each area: > > * ISO 3166-1 alpha-2, a two-letter system with many applications, > most notably the Internet top-level domains (ccTLD) for countries. > * ISO 3166-1 alpha-3, a three-letter system. > * ISO 3166-1 numeric, a three-digit numerical system, which is > identical to that defined by the United Nations Statistical Division. > > Although this would usually be only used in userspace IEEE-802.11d > has made use of ISO-3166-1 alpha 3. This mapping was added > to enhance stack support for IEEE-802.11d and 802.11 Regulatory > Domain control. ieee80211_regdomains makes use of this module > by creating a map of iso3166 alpha3 country code to stack > regulatory domain. But if 802.11d only requires alpha 3, why put all the other stuff into the kernel as well? johannes - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On 10/23/06, Johannes Berg <[EMAIL PROTECTED]> wrote: On Mon, 2006-10-23 at 18:41 -0400, Luis R. Rodriguez wrote: > The current setup on d80211.h makes regulatory domains device > specific. I believe this should be changed to be stack-specific -- > that is, all drivers adhere to the restrictions set by the stack's > current regulatory domain. There should be a way to have a certain device restrict that even further, if the driver wants to allow operation only in a domain that the device has been certified for (because it may malfunction otherwise, for example). Sure good idea -- we can provide a device specific regulatory domain if necessary. We can easily introduce a device_regdomains linked list on the ieee80211_conf which if not empty the driver will use it, else the stack regdomain is used. The ieee80211_regdomains module already provides the interfaces for the manipulation of such list. Pretty easy fix, fortunately. I'll probably have more comments later, really tired now though. Great, thanks. Luis - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] [PATCH 0/3] Add Regulatory Domain support to d80211
On Mon, 2006-10-23 at 18:41 -0400, Luis R. Rodriguez wrote: > The current setup on d80211.h makes regulatory domains device > specific. I believe this should be changed to be stack-specific -- > that is, all drivers adhere to the restrictions set by the stack's > current regulatory domain. There should be a way to have a certain device restrict that even further, if the driver wants to allow operation only in a domain that the device has been certified for (because it may malfunction otherwise, for example). I'll probably have more comments later, really tired now though. johannes signature.asc Description: This is a digitally signed message part
