Re: wireless: recap of current issues (configuration)
Am Sonntag 15 Januar 2006 21:11 schrieb Johannes Berg: > [iwconfig mode ...] > > Yeah, I agree with this, it is much cleaner to handle in the kernel. > Think about the issues if you have a struct net_device that has 250 > bytes of "payload" for the struct virtual_sta_device in it and you want > to switch that to a struct virtual_monitor_device. Icky. Well, nobody forces you to allocate dev->priv together with the net_device, you can set and change this pointer yourself. So I don't see a problem here. Stefan - 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: wireless: recap of current issues (configuration)
On Jan 17, 2006, at 13:41, Stuffed Crust wrote: On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote: If I have told my equipment to obey UK law I expect it to do so. If I hop on the train to France and forget to revise my configuration I'd prefer it also believed the APs It's not that you might forget to revise your configuration, but that the vast majority of users will not revise anything, and still expect things to "just work". Kind of like multi-band cell phones. Alan's point is still very valid. From a poweruser point of view, if I specifically tell my wireless client "You must obey US laws", and then I wander over past a broken imported AP, I don't want my client to _expand_ its allowable range. IMHO, userspace should be able to forcibly restrict wireless frequencies to a certain regdomain (or leave unrestricted and passive-scan-only), and specify how AP/ configured regdomains act. Given the range of possibilities, I think that a userspace daemon monitoring events and dynamically configuring the useable frequencies would best. That way the userspace daemon could be configured to ignore APs, union/intersect the APs with the configured regdomain, ignore the configured regdomain in the presence of APs, etc. Cheers, Kyle Moffett -- I lost interest in "blade servers" when I found they didn't throw knives at people who weren't supposed to be in your machine room. -- Anthony de Boer - 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote: > If I have told my equipment to obey UK law I expect it to do so. If I > hop on the train to France and forget to revise my configuration I'd > prefer it also believed the APs It's not that you might forget to revise your configuration, but that the vast majority of users will not revise anything, and still expect things to "just work". Kind of like multi-band cell phones. This isn't that big of a deal in the 2.4GHz band, but when you start talking about 5GHz, especially in France, things get a lot trickier. Of course, all of this automagic "just work" crap only affects the STAs. For AP operation, we have to trust the user to set the correct locale -- I don't see any way of including a sane "just-works" default in the stock kernel.org tree, so I think the default should be be "none". This way the user is forced to explicitly set the regdomain in order for the AP startup to succeed. ...and pray that the AP isn't migrating to a different regdomain, but there's really nothing anyone can do about that. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpgMqdzpwaQM.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 10:24:41PM +, Alan Cox wrote: > I would expect equipment to honour the subset of configurations that > meet BOTH the regulatory domain the system believes it exists within > (which may change dynamically!) AND the AP advertisement. > > If I have told my equipment to obey UK law I expect it to do so. If I > hop on the train to France and forget to revise my configuration I'd > prefer it also believed the APs Yes, this is an excellent point. I suppose this could result in a non-functional configuration, but that is probably better than conflicting w/ the local authorities... :-) 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: wireless: recap of current issues (configuration)
On Llu, 2006-01-16 at 14:06 -0500, John W. Linville wrote: > If regulators come down on someone, it seems like common sense > that they would be more lenient on mobile stations complying with a > misconfigured AP than they would be with a mobile station ignoring a > properly configured AP? I know expecting common sense from government > regulators is optimistic, but still... :-) I can't guess on the subject of US regulators but for the UK experience in other communities (eg amateur radio), and public statements indicate that their high priorities are interference with emergency services and the like. Concerns of direct relevance are - transmitting on unlicensed frequencies (and 802.11 channel allocations are dependant on nation - even within the EU) - power violation - anything else causing interference to other legitimate users at a radio level I would expect equipment to honour the subset of configurations that meet BOTH the regulatory domain the system believes it exists within (which may change dynamically!) AND the AP advertisement. If I have told my equipment to obey UK law I expect it to do so. If I hop on the train to France and forget to revise my configuration I'd prefer it also believed the APs Alan - 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 10:16:06PM +0200, Samuel Ortiz wrote: > Well, I'd rather trust a governement regulated network than my neighbour's > AP ;-) In fact, some phones set their 802.11 regulatory domain based on > the information they received from a somehow government regulated network, > e.g. a GSM one. The asumption is that 802.11d information, like current "regdomain" settings, is fixed and not user-configurable. If the regdomain is changeable by the user, that unit would not be approved for sale in that particular locale. (Now 802.11d doesn't specify what to do when you hear two conflicting 802.11d beacons there go those assumptions again..) Stations respecting 802.11d rules are not allowed to transmit on any supported frequency until they hear an AP on that frequency first. This essentially means that all scans are passive until we hear an AP, and we can't transmit on any other (presumably still silent) frequencies unless we hear an 802.11d beacon that says we can. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpVn6NjQ023S.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 12:14:08PM -0800, Sam Leffler wrote: > Please read what I wrote again. Station mode power save work involves > communicating with the ap and managing the hardware. The first > interacts with bg scanning. We haven't even talked about how to handle > sta mode power save. I think we're arguing over semantics; what's important here is that the STA tells the AP to buffer frames while we're performing a scan, correct? > If you wait until the end of the scan to return to the bss channel then > you potentially miss buffered mcast frames. You can up the station's > listen interval but that only gets you so far. As I said there are > tradeoffs in doing this. An excellent point. This is particularly relevant for APs that have a DTIM interval of 1 -- if you're doing a passive scan, the dwell time on that other channel (you need at least one beacon interval) could cause you to miss bufferend MCAST frames. In all fairness I don't think I've seen any implementations that handle this cleanly. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpC0Fzdhpy7E.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Mon, 16 Jan 2006, ext John W. Linville wrote: > On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote: > > On Mon, 16 Jan 2006, ext Stuffed Crust wrote: > > > > > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote: > > > > Regarding 802.11d and regulatory domains, the stack should also be able > > > > to > > > > stick to one regulatory domain if asked so by userspace, whatever the > > > > APs > > > > around tell us. > > > > > > ...and in doing so, violate the local regulatory constraints. :) > > The other option is to conform to whatever the AP you associate with > > advertises. In fact, this is how it should be done according to 802.11d. > > Unfortunately, this doesn't ensure local regulatory constraints compliance > > unless you expect each and every APs to do the Right Thing ;-) > > If regulators come down on someone, it seems like common sense > that they would be more lenient on mobile stations complying with a > misconfigured AP than they would be with a mobile station ignoring a > properly configured AP? I know expecting common sense from government > regulators is optimistic, but still... :-) Well, I'd rather trust a governement regulated network than my neighbour's AP ;-) In fact, some phones set their 802.11 regulatory domain based on the information they received from a somehow government regulated network, e.g. a GSM one. Cheers, Samuel. - 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: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote: The way you implement bg scanning is to notify the ap you are going into power save mode before you leave the channel (in sta mode). Hence bg scanning and power save operation interact. That is not "powersave operation" -- that is telling the AP we are going into powersave, but not actually going into powersave -- Actual powersave operation would need to be disabled if we go into a scan, as we need to have the rx path powered up and ready to hear anything out there for the full channel dwell time. Please read what I wrote again. Station mode power save work involves communicating with the ap and managing the hardware. The first interacts with bg scanning. We haven't even talked about how to handle sta mode power save. See above. Doing bg scanning well is a balancing act and restoring hardware state is the least of your worries (hopefully); e.g. what's the right thing to do when you get a frame to transmit while off-channel scanning, how often should you return to the bss channel? Disallow all other transmits (either by failing them altogether, or by buffering them up, which I think is better) while performing the scan. Not necessarily in my experience. If we are (continually) scanning because we don't have an association, then we shouldn't be allowing any traffic through the stack anyway. If you do not have an association you are not doing bg scanning. At the end of each scan pass, you return to the original channel, then return "scan complete" to the stack/userspace. at this point any pending transmits can go out, and if another scan pass is desired, it will happen then. If you wait until the end of the scan to return to the bss channel then you potentially miss buffered mcast frames. You can up the station's listen interval but that only gets you so far. As I said there are tradeoffs in doing this. Er, you need to listen to at least beacons from other ap's if you're in 11g so you can detect overlapping bss and enable protection. There are other ways to handle this but that's one. If you can't hear the traffic, then it doesn't count for purposes of ER protection -- but that said, this only matters for AP operation, so APs shouldn't filter out anyone else's becacons. STAs should respect the "use ER Protection" bit in the AP's beacon, so can filter out traffic that doesn't match the configured BSSID. Sorry I meant this was needed for ap operation. Oh, I know. I've burned out many brain cells trying to build supportable solutions for our customers. I don't recall seeing well-developed scanning code in either of the proposed stacks. I've only looked into the pre-2.6-merged HostAP stack, so I can't comment on what's publically available. I'll have a look at the GPL'ed DeviceScape stack when I have more time. Most of what I've going on about is derived from my experience from commercial 802.11 work I've done over the past few years. Ditto. Sam - 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 10:00:18AM -0800, Sam Leffler wrote:
> Perhaps you haven't hit some of the more recent standards that place
> more of a burden on the ap implementation? Also some vendor-specific
> protocol features suck up space for ap mode only and it is nice to be
> able to include them only as needed.
While there is more work to be done on the AP side, and that code may
even be easily wrapped in an #ifdef, the majority of the complexity is
shared by both the station and the AP. It's worth mentioning that the
802.11 specs do not generally differentiate between "APs vs non-APs" --
they're all "STAs" of equal capabilities.
This is at least true of 802.11d, 802.11e, 802.11i
(supplicant/authenticator notwithstanding), 802.11j, and 802.11k. The
general difference is that the AP needs to be aware of the state of its
associated STAs, and perform different actions depending on configured
policy and the STAs' states, whereas the STAs generally do what the AP
tells them to do.
> There are several advantages to splitting up the code such as reduced
> audit complexity and real space savings but I agree that it is an open
> question whethere there's a big gain to modularizing the code by
> operating mode.
I agree that there would be some space savings, but they'd be relatively
small, at least if the stack is designed to be generic. This would make
the most difference for tiny/embedded systems -- but they'd want to use
#ifdefs to disable all AP code entirely, which includes all of the "if
(ap_mode) { } else { }" clauses that would litter the whole codebase,
regardless of modularity. (then if we use function pointers... that's a
*lot* of virtual functions..)
- Solomon
--
Solomon Peachy ICQ: 1318344
Melbourne, FL
Quidquid latine dictum sit, altum viditur.
pgphsDiiWYObx.pgp
Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Mon, 16 Jan 2006, ext Stuffed Crust wrote: > You may hear another beacon when the STA is awake, you may not. BSSID > filtering has nothing to do with 802.11 power save, but rather is > intented to reduce the host load (interrupts, processing overhead) and > thus the host power consumption. I know that and I know a bit about 802.11 PS as well. I was talking about host powersaving, not 802.11. Sorry for the confusion. What I meant is that having an 802.11 stack capable of living with less than a beacon every couple of beacon intervals would be nice as well. Cheers, Samuel. - 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 09:07:52PM +0200, Samuel Ortiz wrote: > That is true, thin MACs usually don't filter beacons on the same channel. > But in some cases (mainly power saving), you really want to avoid > receiving useless beacons and having the host woken up for each of them. > You may even want to not receive all the useful ones (the ones coming from > the AP you're joined with) if your softmac allows that. BSSID filtering doesn't matter as far as 802.11 powersave is concerned -- the power savings come from disabling the RF/BBP components. In other words, you can't receive or transmit traffic. If you're respecting the AP's beacon interval/DTIM settings, you only wake up every couple of beacon intervals and listen for a beacon. IF there's traffic waiting for you, then you wake up your transmitter, send out a PSPOLL (or NULL/PSEnd) frame, get your traffic, then go back to sleep again. You may hear another beacon when the STA is awake, you may not. BSSID filtering has nothing to do with 802.11 power save, but rather is intented to reduce the host load (interrupts, processing overhead) and thus the host power consumption. > This kind of beacon filtering is a big power saver, which is one of the > most important requirement for some platforms (phones, PDA, etc...). You need to be clear if you're talking about 802.11 powersave, versus "power savings stemming from reducing the load on the host system", which is where BSSID filtering is beneficial. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpCscV5MHtpv.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 09:54:15AM -0800, Sam Leffler wrote: > The way you implement bg scanning is to notify the ap you are going into > power save mode before you leave the channel (in sta mode). Hence bg > scanning and power save operation interact. That is not "powersave operation" -- that is telling the AP we are going into powersave, but not actually going into powersave -- Actual powersave operation would need to be disabled if we go into a scan, as we need to have the rx path powered up and ready to hear anything out there for the full channel dwell time. > See above. Doing bg scanning well is a balancing act and restoring > hardware state is the least of your worries (hopefully); e.g. what's the > right thing to do when you get a frame to transmit while off-channel > scanning, how often should you return to the bss channel? Disallow all other transmits (either by failing them altogether, or by buffering them up, which I think is better) while performing the scan. If we are (continually) scanning because we don't have an association, then we shouldn't be allowing any traffic through the stack anyway. At the end of each scan pass, you return to the original channel, then return "scan complete" to the stack/userspace. at this point any pending transmits can go out, and if another scan pass is desired, it will happen then. > Er, you need to listen to at least beacons from other ap's if you're in > 11g so you can detect overlapping bss and enable protection. There are > other ways to handle this but that's one. If you can't hear the traffic, then it doesn't count for purposes of ER protection -- but that said, this only matters for AP operation, so APs shouldn't filter out anyone else's becacons. STAs should respect the "use ER Protection" bit in the AP's beacon, so can filter out traffic that doesn't match the configured BSSID. > >Oh, I know. I've burned out many brain cells trying to build > >supportable solutions for our customers. > > I don't recall seeing well-developed scanning code in either of the > proposed stacks. I've only looked into the pre-2.6-merged HostAP stack, so I can't comment on what's publically available. I'll have a look at the GPL'ed DeviceScape stack when I have more time. Most of what I've going on about is derived from my experience from commercial 802.11 work I've done over the past few years. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpftRIsaAE60.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Mon, 16 Jan 2006, ext Stuffed Crust wrote: > Background scanning, yes -- but there are all sorts of different > thresholds and types of 'scanning' to be done, depending on how > disruptive you are willing to be, and how capable the hardware is. Most > thin MACs don't filter out foreign BSSIDs on the same channel when > you're joined, which makes some things a lot easier. That is true, thin MACs usually don't filter beacons on the same channel. But in some cases (mainly power saving), you really want to avoid receiving useless beacons and having the host woken up for each of them. You may even want to not receive all the useful ones (the ones coming from the AP you're joined with) if your softmac allows that. This kind of beacon filtering is a big power saver, which is one of the most important requirement for some platforms (phones, PDA, etc...). Cheers, Samuel. - 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 08:51:31PM +0200, Samuel Ortiz wrote: > On Mon, 16 Jan 2006, ext Stuffed Crust wrote: > > > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote: > > > Regarding 802.11d and regulatory domains, the stack should also be able to > > > stick to one regulatory domain if asked so by userspace, whatever the APs > > > around tell us. > > > > ...and in doing so, violate the local regulatory constraints. :) > The other option is to conform to whatever the AP you associate with > advertises. In fact, this is how it should be done according to 802.11d. > Unfortunately, this doesn't ensure local regulatory constraints compliance > unless you expect each and every APs to do the Right Thing ;-) If regulators come down on someone, it seems like common sense that they would be more lenient on mobile stations complying with a misconfigured AP than they would be with a mobile station ignoring a properly configured AP? I know expecting common sense from government regulators is optimistic, but still... :-) Of course when we are the AP, the ability to adjust these parameters could be very important. No? 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: wireless: recap of current issues (configuration)
On Mon, 16 Jan 2006, ext Stuffed Crust wrote: > On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote: > > Regarding 802.11d and regulatory domains, the stack should also be able to > > stick to one regulatory domain if asked so by userspace, whatever the APs > > around tell us. > > ...and in doing so, violate the local regulatory constraints. :) The other option is to conform to whatever the AP you associate with advertises. In fact, this is how it should be done according to 802.11d. Unfortunately, this doesn't ensure local regulatory constraints compliance unless you expect each and every APs to do the Right Thing ;-) > Allowing > the user to change the regulatory domain at will.. is a rather fuzzy > legal area, to say the least. IMHO, strictly sticking to 802.11d is also somehow legally fuzzy as you're as legal as the network you're joining. Cheers, Samuel. - 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: wireless: recap of current issues (configuration)
On Mon, 2006-01-16 at 12:28 -0500, Stuffed Crust wrote: > Scans should be specified as "non-distruptive" so the hardware driver > has to twiddle whatever bits are necessary to return the hardware to the > same state that it was in before the scan kicked in. Beyond that, the > scanning smarts are all in the 802.11 stack. The driver should be as > dumb as possible. :) This is quite important... from a user perspective, it might be 2, 5, or 15 seconds before the card can actually scan all channels. Unfortunately, background (passive) scanning by definition can't find all access points, so you're going to need to do active scanning. However, that active scanning should be controlled by userspace, not the driver. Only userspace knows what policies the user him/herself has set on powersaving mode. > Background scanning, yes -- but there are all sorts of different > thresholds and types of 'scanning' to be done, depending on how > disruptive you are willing to be, and how capable the hardware is. Most > thin MACs don't filter out foreign BSSIDs on the same channel when > you're joined, which makes some things a lot easier. Scanning has the tradeoff of updated network list vs. saving power + network disruption. The user, or programs delegated by the user, need to make that choice, not the stack or the driver. - Furthermore, and this is also extremely important, user apps need to know when the scan is done. From my look at drivers, _all_ cards know when the hardware is in scanning states, and when its done. What many don't do is communicate that information to userspace via wireless events. The userspace app that requested scanning is then stuck busy-waiting for the SIOCGIWSCAN to return success, which just sucks. Much better if all drivers had the wireless event so that the userspace app could just fire off the scan with SIOCSIWSCAN, and parse the results when the event comes back rather than spinning. In the netlink world, this would of course be done by multicasting the "Scan Done" message to all interested clients, which would be just as good. 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: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote: I really don't see why a plain STA mode card should be required to carry around all the code required for AP operation -- handling associations of clients, powersave management wrt. buffering, ... Sure, fragmentation From the perspective of the hardware driver, there is little AP or STA-specific code, especially when IBSS is thrown in. Thick MACs excepted, there's little more than "frame tx/rx, and hardware control twiddling". The AP/STA smarts happen in the 802.11 stack. And, speaking from experience, it is very hard to separate them cleanly, at least not without incurring even more overall complexity and bloat. It's far simpler to build them intertwined, then add a bunch of #ifdefs if you want to disable AP or STA mode individually to save space. Perhaps you haven't hit some of the more recent standards that place more of a burden on the ap implementation? Also some vendor-specific protocol features suck up space for ap mode only and it is nice to be able to include them only as needed. There are several advantages to splitting up the code such as reduced audit complexity and real space savings but I agree that it is an open question whethere there's a big gain to modularizing the code by operating mode. Sam - 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: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote: The above is a great synopsis but there is more. For example to support roaming (and sometimes for ap operation) you want to do background scanning; this ties in to power save mode if operating as a station. Opportunistic roaming is one of those things that has many knobs to twiddle, and depends a lot on the needs of the users. But we're not actually in powersave mode -- the 802.11 stack can spit out the NULL frames to tell the AP to buffer traffic for us. This is trivial to do. The way you implement bg scanning is to notify the ap you are going into power save mode before you leave the channel (in sta mode). Hence bg scanning and power save operation interact. Scans should be specified as "non-distruptive" so the hardware driver has to twiddle whatever bits are necessary to return the hardware to the same state that it was in before the scan kicked in. Beyond that, the scanning smarts are all in the 802.11 stack. The driver should be as dumb as possible. :) See above. Doing bg scanning well is a balancing act and restoring hardware state is the least of your worries (hopefully); e.g. what's the right thing to do when you get a frame to transmit while off-channel scanning, how often should you return to the bss channel? Background scanning, yes -- but there are all sorts of different thresholds and types of 'scanning' to be done, depending on how disruptive you are willing to be, and how capable the hardware is. Most thin MACs don't filter out foreign BSSIDs on the same channel when you're joined, which makes some things a lot easier. Er, you need to listen to at least beacons from other ap's if you're in 11g so you can detect overlapping bss and enable protection. There are other ways to handle this but that's one. Further you want to order your channel list to hit the most likely channels first in case you are scanning for a specific ap--e.g. so you can stop the foreground scan and start to associate. With my scenarios, the driver performs the sweep in the order it was given -- if the hardware supports it, naturally. Channel ordering is useful no matter who specifies it. If you offload the ordering to the upper layers then they need to be aware of the regdomain constraints. Probably not a big deal but then you need to synchronize info between layers or export it. And there's other regdomain-related info that may want to be considered such as max txpower. I'm just saying if you want to do a good job there's lots of work here. In terms of beacon miss processing some parts have a hardware beacon miss interrupt based on missed consecutive beacons but others require you to detect beacon miss in software. Other times you need s/w bmiss detection because you're doing something like build a repeater when the station virtual device can't depend on the hardware to deliver a bmiss interrupt. Of course. The stack is going to need a set of timers regardless of the hardware's capabilities, but having (sane) hardware beacon miss detection capabilities makes it a bit more robust. Scanning (and roaming) is really a big can 'o worms. Oh, I know. I've burned out many brain cells trying to build supportable solutions for our customers. I don't recall seeing well-developed scanning code in either of the proposed stacks. Sam - 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: wireless: recap of current issues (configuration)
On Mon, Jan 16, 2006 at 03:55:55PM +0100, Johannes Berg wrote: > I really don't see why a plain STA mode card should be required to carry > around all the code required for AP operation -- handling associations > of clients, powersave management wrt. buffering, ... Sure, fragmentation From the perspective of the hardware driver, there is little AP or STA-specific code, especially when IBSS is thrown in. Thick MACs excepted, there's little more than "frame tx/rx, and hardware control twiddling". The AP/STA smarts happen in the 802.11 stack. And, speaking from experience, it is very hard to separate them cleanly, at least not without incurring even more overall complexity and bloat. It's far simpler to build them intertwined, then add a bunch of #ifdefs if you want to disable AP or STA mode individually to save space. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgp5uPDYtJwb5.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Sun, Jan 15, 2006 at 11:53:55AM -0800, Sam Leffler wrote: > The above is a great synopsis but there is more. For example to support > roaming (and sometimes for ap operation) you want to do background > scanning; this ties in to power save mode if operating as a station. Opportunistic roaming is one of those things that has many knobs to twiddle, and depends a lot on the needs of the users. But we're not actually in powersave mode -- the 802.11 stack can spit out the NULL frames to tell the AP to buffer traffic for us. This is trivial to do. Scans should be specified as "non-distruptive" so the hardware driver has to twiddle whatever bits are necessary to return the hardware to the same state that it was in before the scan kicked in. Beyond that, the scanning smarts are all in the 802.11 stack. The driver should be as dumb as possible. :) Background scanning, yes -- but there are all sorts of different thresholds and types of 'scanning' to be done, depending on how disruptive you are willing to be, and how capable the hardware is. Most thin MACs don't filter out foreign BSSIDs on the same channel when you're joined, which makes some things a lot easier. > Further you want to order your channel list to hit the most likely > channels first in case you are scanning for a specific ap--e.g. so you > can stop the foreground scan and start to associate. With my scenarios, the driver performs the sweep in the order it was given -- if the hardware supports it, naturally. > In terms of beacon miss processing some parts have a hardware beacon > miss interrupt based on missed consecutive beacons but others require > you to detect beacon miss in software. Other times you need s/w bmiss > detection because you're doing something like build a repeater when > the station virtual device can't depend on the hardware to deliver a > bmiss interrupt. Of course. The stack is going to need a set of timers regardless of the hardware's capabilities, but having (sane) hardware beacon miss detection capabilities makes it a bit more robust. > Scanning (and roaming) is really a big can 'o worms. Oh, I know. I've burned out many brain cells trying to build supportable solutions for our customers. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpAD1yPYoAut.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Sun, Jan 15, 2006 at 09:05:33PM +0200, Samuel Ortiz wrote: > Regarding 802.11d and regulatory domains, the stack should also be able to > stick to one regulatory domain if asked so by userspace, whatever the APs > around tell us. ...and in doing so, violate the local regulatory constraints. :) Although I believe 802.11d specifies that the 802.11d beacons should trump whatever the user specifies. (of course, 802.11d doesn't say what to do when there are APs out there that disagree...) While I feel it should be *posisble* to do so, the default should be to query the hardware for its factory default, and go with that. Allowing the user to change the regulatory domain at will.. is a rather fuzzy legal area, to say the least. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpDp0Oue64XB.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Mon, 2006-01-16 at 15:23 +0100, Jiri Benc wrote: > You are right. But it breaks compatibility with iwconfig unless we > emulate 'iwconfig mode' command by deleting and adding interface. This > means some events are generated, hotplug/udev gets involved etc. In the > worst case it can mean that we end up with interface with a different > name. Eh, right. In that case, I guess that dropping compatibility here would be the only solution. Other iwconfig could still work though. I don't know where to draw the line. > I'm not sure about your concept of softmac modules. I wrote an e-mail > some time ago explaining why I don't think it is useful and I haven't > got any reply. Please, could you answer that e-mail first? (See > http://marc.theaimsgroup.com/?l=linux-netdev&m=113404158202233&w=2) I didn't really participate much in that thread. Maybe softmac was a bad example for being a module -- it just seemed to fit the current model that the in-kernel ieee80211 module follows. > Could you also explain how would you implement separate module for AP > mode? How would you bind that module to the rest of ieee80211, > especially in the rx path? Well, if you look at p80211 that davem wrote there are functions for handling each type of the different receive frames. These could easily be multiplexed into function pointers the module provides. I really don't see why a plain STA mode card should be required to carry around all the code required for AP operation -- handling associations of clients, powersave management wrt. buffering, ... Sure, fragmentation is needed for all, so it needs to be in the common code, and it might make a lot of sense to unify WDS and STA modes, but AP mode requires fundamentally different things and a lot of code that will never be called in STA operation. Putting it into the same modules and then probably into the same structures just encourages bloat and interdependencies that I don't think should be there. johannes signature.asc Description: This is a digitally signed message part
Re: wireless: recap of current issues (configuration)
On Fri, 13 Jan 2006 23:32:02 +0100, Johannes Berg wrote: > IMHO there's not much point in allowing changes. I have a feeling that > might create icky issues you don't want to have to tackle when the > solution is easy by just not allowing it. Part of my thinking is that > different virtual types have different structures associated, so > changing it needs re-creating structures anyway. You are right. But it breaks compatibility with iwconfig unless we emulate 'iwconfig mode' command by deleting and adding interface. This means some events are generated, hotplug/udev gets involved etc. In the worst case it can mean that we end up with interface with a different name. > And different virtual > device types might even be provided by different kernel modules so you > don't carry around AP mode if you don't need it. I'm not sure about your concept of softmac modules. I wrote an e-mail some time ago explaining why I don't think it is useful and I haven't got any reply. Please, could you answer that e-mail first? (See http://marc.theaimsgroup.com/?l=linux-netdev&m=113404158202233&w=2) Could you also explain how would you implement separate module for AP mode? How would you bind that module to the rest of ieee80211, especially in the rx path? Thanks, -- 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: wireless: recap of current issues (configuration)
On Sun, Jan 15, 2006 at 11:39:41AM -0800, Sam Leffler wrote: > The big stumbling block I found to going with virtual devices is that it > affects user apps. I looked at doing things like auto-create a station > device for backwards compatibility but decided against it. If you > really want this behaviour it can be done by user code. Right, no reason not to just put this into a hotplug script, is there? Is it, when it comes down to it, significantly different than automating firmware loads for the user? -m -- Mike Kershaw/Dragorn <[EMAIL PROTECTED]> GPG Fingerprint: 3546 89DF 3C9D ED80 3381 A661 D7B2 8822 738B BDB1 Experts in ancient Greek culture say that people back then didn't see their thoughts as belonging to them. When they had a thought, it occured to them as a god or goddess giving them an order. Apollo was telling them to be brave. Athena was telling them to fall in love. Now people hear a commercial for sour cream potato chips and rush out to buy. -- Chuck Palahniuk pgpW4Zsr4jF8i.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
On Sun, 15 Jan 2006, ext Stuffed Crust wrote: > * Knowing the hardware frequency capabilities, the 802.11 stack applies >802.11d and regdomain rules to the available frequency set, and Regarding 802.11d and regulatory domains, the stack should also be able to stick to one regulatory domain if asked so by userspace, whatever the APs around tell us. Cheers, Samuel. - 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: wireless: recap of current issues (configuration)
On Sun, 2006-01-15 at 12:08 -0800, Sam Leffler wrote: > To do what you describe I would create a monitor mode device, switch > channel, then destroy it. All the time you leave the station device > unchanged, though you probably need to disable it. This may not be > possible with all devices--i.e. for those that require different > firmware to do monitoring you will be restricted to a single virtual > device and/or operating mode. Yeah, I agree with this, it is much cleaner to handle in the kernel. Think about the issues if you have a struct net_device that has 250 bytes of "payload" for the struct virtual_sta_device in it and you want to switch that to a struct virtual_monitor_device. Icky. johannes signature.asc Description: This is a digitally signed message part
Re: wireless: recap of current issues (configuration)
Stefan Rompf wrote: Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg: Isn't that rather a question of having good user-space tools that make deactivating one type of interface and activating another seamless? Well, it's always easy to point to userspace. However, unregister_netdev() initiates a lot of actions. IPv4 addresses and routes are removed, same for IPv6, IPX, Appletalk etc. Stacked VLAN devices are recursively unregistered (even though I have not tried yet if it works when I create VLANs over 802.3 emulated wlan interfaces ;-), udev bloat runs. And all this stuff has to be restored by the nifty new configuration utility, possibly including ifindex and future protocols. This is from my usage pattern that I want to go into monitor mode on current channel, look at some packets and return to the association without losing layer 3 configuration. So after all, it is IMHO way less painful to handle a mode change in the kernel. To do what you describe I would create a monitor mode device, switch channel, then destroy it. All the time you leave the station device unchanged, though you probably need to disable it. This may not be possible with all devices--i.e. for those that require different firmware to do monitoring you will be restricted to a single virtual device and/or operating mode. Sam - 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: wireless: recap of current issues (configuration)
Stuffed Crust wrote: On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote: This can be accomplished by passing a static table to the register_wiphy_device() call (or perhaps via a struct wiphy_dev parameter) or through a more explicit, dynamic interface like: wiphy_register_supported_frequency(hw, 2412). For completely programmable hardware, the stack should interact with a module like ieee80211_geo, to help ensure the hardware stays within legal limits. While there is much to debate about where to draw the functionality line, completely programmable hardware is the norm these days. ... and said code would be responsible for driving the scanning state machines, and also for more esoteric functions like handling RADAR traps, automatic channel switching, etc. Handling scans is quite interesting -- I've seen hardware which requires manual channel changing (including full RF parameter specification), host timing for the channel dwell time, and manual probe request issuance.. and on the other end of the spectrum, a simple "issue scan" command that takes few, if any, parameters. And unfortunately, many things in between. This leads me to belive that the internal scan workflow should work something like this: * Userspace app issues scan request (aka "refresh AP list") * Knowing the hardware frequency capabilities, the 802.11 stack applies 802.11d and regdomain rules to the available frequency set, and issues multiple internal "scan request" commands to the hardware driver. (eg "perform an initial passive sweep across the entire 2.4G band", "perform an active scan on frequencies 2412->2437 looking for ssid "HandTossed", "perform an active scan on frequencies 5200-5400 looking for ssid "HandTossed", etc) (note that ideally, userspace apps/libs would be at least partially aware of 802.11d rules, but the kernel must do the RightThing if told to "scan all available channels for any access points") * The hardware driver takes this scan request, and maps it into the capabilities of the hardware: Hardware A: (very thin MAC) - Using library code, generates an appropriate probe request frame, translates it into a format the hardware expects/needs, and schedules it appropriately. - Loops through the frequency set specified, and for each: - Issues a channel change command - Immediately transmits the probe request (for active scans) - Dwells for an appropriate time - RX'ed beacon/probe response frames come down as regular 802.11 frames into the stack - Moves to the next channel Hardware B: (thinner MAC) - Using library code, generates an appropriate probe request frame, and translate it into a format the hardware expects. - Program the probe request frame into the hardware as a probe template. - Loops through the frequency set specified, and for each: - Issues a channel change command - Wait for a scan complete signal - RX'ed beacon/probe response frames come down as regular 802.11 frames into the stack - Moves to the next channel Hardware C: (thick MAC, ala prism2 or prism54) - Issues a hardware "scan request" - Waits for the hardware to signal "scan complete" - Requests hardware scan results - For each scan result, the hardware returns: - Translate result into an 802.11 probe response frame and pass down the regular RX path. So as you can see, I think the channel iteration, dwell, etc should be performed by the hardware driver itself, as the variation at the logical "tell the hardware perform a scan" step is so extreme. * Meanwhile, the 802.11 stack is receiving the beacons/probe responses from the hardware via the regular rx path. It diverts these (and other 802.11 management/control) frames, decodes them, and then adds them to the stack's internal list of available stations, updating any internal states/counters as necessary. (These frames could also be echoed to a special netdev interface if desired) (stuff like detecting an AP going away depends on us noticing a lack of beacons arriving, for example. Most hardware does not notify us of this event. Likewise, we should expire other APs from our list if they go away.. etc. For AP operation we need to maintain this STA list, period -- so why not use it across the board? But this is another discussion for another time..) * The 802.11 stack issues a MLME-Scan-Complete notification to userspace. * Interested userspace apps see this event, then query the scan results and presents them to the user in some pretty format, or alternatively perform automatic roaming based on scan results. The above is a great synopsis but there is more. For example to support roaming (and sometimes for ap operation) you want to do
Re: wireless: recap of current issues (configuration)
Stefan Rompf wrote: Am Samstag 14 Januar 2006 14:47 schrieb Ulrich Kunitz: They one problem I can see is scanning over several frequencies. If two virtual devices are doing this at the same time, we have a conflict. Maybe each WiPHY would have only one active interface, I think scanning can be easily serialized. We use a parameter structure that describes which channels / SSIDs should be scanned. The stack guarantees that there will be only one active scan, results are written to a WiPHY device specific list. When querying results, the same structure is used to filter on that list. You must serialize shared state changes. Scanning is just one example but an important one as after a channel change all virtual devices must be notified so, for example, they can recreate beacon frames if they are operating in ap mode. Doing a good job scanning is important if you want roaming to work well (but also is important for ap operation, e.g. when radar detection requires a channel change). Sam - 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: wireless: recap of current issues (configuration)
Stefan Rompf wrote: Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg: [Changing mode of virtual devices] IMHO there's not much point in allowing changes. I have a feeling that might create icky issues you don't want to have to tackle when the solution is easy by just not allowing it. Part of my thinking is that different virtual types have different structures associated, so changing it needs re-creating structures anyway. And different virtual device types might even be provided by different kernel modules so you don't carry around AP mode if you don't need it. Even though it is a bit more work on kernel side, we should allow changing the mode of virtual devices. Let's face it, even though we find multi-BSS capabilities very interesting, 999 of 1000 users won't care due to the two facts that IPW firmware IMHO doesn't allow it and virtual interfaces are limited to one channel anyway. These users rightfully expect to have one interface and be able to do all configurations on it. My experience is that once you can create+destroy virtual devices you'll never want mode changing. From a usability standpoint when you switch modes you typically have to reconfigure lots of settings and doing destroy old followed by create new is easier. Depending on how things tie into hotplug you may also find things getting complicated. Within the kernel having the operating mode of a virtual device not change is very good. First it lets you isolate the rules for mix+match of different virtual devices at create. Second you can partition code so, for example, only code required to support an ap is loaded when an ap mode virtual device exists. There are other less obvious reasons such as firmware-based devices can load firmware based on the operating mode at create time but if you allow mode switching then you need to unload+load on the fly. All these things can be handled with switching modes but the complexity is significant and the gain is minimal. The big stumbling block I found to going with virtual devices is that it affects user apps. I looked at doing things like auto-create a station device for backwards compatibility but decided against it. If you really want this behaviour it can be done by user code. Sam - 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: wireless: recap of current issues (configuration)
Am Sonntag 15 Januar 2006 16:51 schrieb Johannes Berg: > Isn't that rather a question of having good user-space tools that make > deactivating one type of interface and activating another seamless? Well, it's always easy to point to userspace. However, unregister_netdev() initiates a lot of actions. IPv4 addresses and routes are removed, same for IPv6, IPX, Appletalk etc. Stacked VLAN devices are recursively unregistered (even though I have not tried yet if it works when I create VLANs over 802.3 emulated wlan interfaces ;-), udev bloat runs. And all this stuff has to be restored by the nifty new configuration utility, possibly including ifindex and future protocols. This is from my usage pattern that I want to go into monitor mode on current channel, look at some packets and return to the association without losing layer 3 configuration. So after all, it is IMHO way less painful to handle a mode change in the kernel. Stefan - 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: wireless: recap of current issues (configuration)
On Sat, Jan 14, 2006 at 06:41:56PM -0500, Dan Williams wrote: > One other thing: capability. It's not enough to be able to configure > the device, user-space tools also have to know what the device is > capable of before they try touching it. Ie, which ciphers, protocols, > channels, etc. Similar to the IWRANGE ioctl that there is now. Half > the problem now is that you can't reliably tell what drivers support > which features, or how much they support a particular feature. This is an absolute requirement, especially when talking about encryption. You'd need, for example: CAP_WEP_64 CAP_WEP_128 CAP_WEP_256 (non-standard, but often supported) CAP_TKIP CAP_MICHAELMIC CAP_AES_CCMP Then, to make things more complicated: CAP_KEYMAPPING (can the hardware do keymapping?) CAP_CAN_DISABLE_HWCRYPT (so if the hardware can't do TKIP, can we perform it on the host?) And to make things even more complicated, I've seen hardware that supports disabling of hardware crypto, but not toggling it on the fly, thanks to never-fixed hardware bugs. (you have to perform a full reset/firmware load cycle. this means you end up disabling host crypto altogether, at least if any of the networks you want to support include CCMP... Other quirks -- hardware that requires host MICHAEL on transmits, but handles it on reception, unless if the received frames are fragmented. Other hardware that does keymapping on rx frames, but for transmits takes the raw keydata in the tx descriptor. (but still requires host MICHAEL) The list goes on and on.. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgpIHmUBM4zFR.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
Stefan Rompf wrote: > Even though it is a bit more work on kernel side, we should allow changing > the > mode of virtual devices. Let's face it, even though we find multi-BSS > capabilities very interesting, 999 of 1000 users won't care due to the two > facts that IPW firmware IMHO doesn't allow it and virtual interfaces are > limited to one channel anyway. These users rightfully expect to have one > interface and be able to do all configurations on it. Isn't that rather a question of having good user-space tools that make deactivating one type of interface and activating another seamless? 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: wireless: recap of current issues (configuration)
On Sat, Jan 14, 2006 at 05:07:01PM -0500, Jeff Garzik wrote: > >This can be accomplished by passing a static table to the > >register_wiphy_device() call (or perhaps via a struct wiphy_dev > >parameter) or through a more explicit, dynamic interface like: > > > > wiphy_register_supported_frequency(hw, 2412). > > For completely programmable hardware, the stack should interact with a > module like ieee80211_geo, to help ensure the hardware stays within > legal limits. While there is much to debate about where to draw the functionality line, completely programmable hardware is the norm these days. ... and said code would be responsible for driving the scanning state machines, and also for more esoteric functions like handling RADAR traps, automatic channel switching, etc. Handling scans is quite interesting -- I've seen hardware which requires manual channel changing (including full RF parameter specification), host timing for the channel dwell time, and manual probe request issuance.. and on the other end of the spectrum, a simple "issue scan" command that takes few, if any, parameters. And unfortunately, many things in between. This leads me to belive that the internal scan workflow should work something like this: * Userspace app issues scan request (aka "refresh AP list") * Knowing the hardware frequency capabilities, the 802.11 stack applies 802.11d and regdomain rules to the available frequency set, and issues multiple internal "scan request" commands to the hardware driver. (eg "perform an initial passive sweep across the entire 2.4G band", "perform an active scan on frequencies 2412->2437 looking for ssid "HandTossed", "perform an active scan on frequencies 5200-5400 looking for ssid "HandTossed", etc) (note that ideally, userspace apps/libs would be at least partially aware of 802.11d rules, but the kernel must do the RightThing if told to "scan all available channels for any access points") * The hardware driver takes this scan request, and maps it into the capabilities of the hardware: Hardware A: (very thin MAC) - Using library code, generates an appropriate probe request frame, translates it into a format the hardware expects/needs, and schedules it appropriately. - Loops through the frequency set specified, and for each: - Issues a channel change command - Immediately transmits the probe request (for active scans) - Dwells for an appropriate time - RX'ed beacon/probe response frames come down as regular 802.11 frames into the stack - Moves to the next channel Hardware B: (thinner MAC) - Using library code, generates an appropriate probe request frame, and translate it into a format the hardware expects. - Program the probe request frame into the hardware as a probe template. - Loops through the frequency set specified, and for each: - Issues a channel change command - Wait for a scan complete signal - RX'ed beacon/probe response frames come down as regular 802.11 frames into the stack - Moves to the next channel Hardware C: (thick MAC, ala prism2 or prism54) - Issues a hardware "scan request" - Waits for the hardware to signal "scan complete" - Requests hardware scan results - For each scan result, the hardware returns: - Translate result into an 802.11 probe response frame and pass down the regular RX path. So as you can see, I think the channel iteration, dwell, etc should be performed by the hardware driver itself, as the variation at the logical "tell the hardware perform a scan" step is so extreme. * Meanwhile, the 802.11 stack is receiving the beacons/probe responses from the hardware via the regular rx path. It diverts these (and other 802.11 management/control) frames, decodes them, and then adds them to the stack's internal list of available stations, updating any internal states/counters as necessary. (These frames could also be echoed to a special netdev interface if desired) (stuff like detecting an AP going away depends on us noticing a lack of beacons arriving, for example. Most hardware does not notify us of this event. Likewise, we should expire other APs from our list if they go away.. etc. For AP operation we need to maintain this STA list, period -- so why not use it across the board? But this is another discussion for another time..) * The 802.11 stack issues a MLME-Scan-Complete notification to userspace. * Interested userspace apps see this event, then query the scan results and presents them to the user in some pretty format, or alternatively perform automatic roaming based on scan results. - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine d
Re: wireless: recap of current issues (configuration)
Am Samstag 14 Januar 2006 14:47 schrieb Ulrich Kunitz: > They one problem I can see is scanning over several frequencies. > If two virtual devices are doing this at the same time, we have a > conflict. Maybe each WiPHY would have only one active interface, I think scanning can be easily serialized. We use a parameter structure that describes which channels / SSIDs should be scanned. The stack guarantees that there will be only one active scan, results are written to a WiPHY device specific list. When querying results, the same structure is used to filter on that list. Stefan - 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: wireless: recap of current issues (configuration)
Am Freitag 13 Januar 2006 23:32 schrieb Johannes Berg: > [Changing mode of virtual devices] > > IMHO there's not much point in allowing changes. I have a feeling that > might create icky issues you don't want to have to tackle when the > solution is easy by just not allowing it. Part of my thinking is that > different virtual types have different structures associated, so > changing it needs re-creating structures anyway. And different virtual > device types might even be provided by different kernel modules so you > don't carry around AP mode if you don't need it. Even though it is a bit more work on kernel side, we should allow changing the mode of virtual devices. Let's face it, even though we find multi-BSS capabilities very interesting, 999 of 1000 users won't care due to the two facts that IPW firmware IMHO doesn't allow it and virtual interfaces are limited to one channel anyway. These users rightfully expect to have one interface and be able to do all configurations on it. Stefan - 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: wireless: recap of current issues (configuration)
John W. Linville wrote: > Configuration seems to be coalescing around netlink. Among other > things, this technology provides for muliticast requests and > asynchronous event notification. On the other hand, the tree structure of sysfs can handle the resource exclusivity and sharing naturaly. A proposal of the layout: template - template of device that can be created profile - exclusive set of templates and other resources plain SoftMAC card: /sys/class/ieee80211/phy0/profile0/template0/mode # ap | | /... # ap specific stuff | | | *--->/template1/mode # sta | | /... # sta specific stuff | | | *--->/template2/mode # rfmon | /... # rfmon specific stuff | *->/profile /channel /txpower /... # other phy specific stuff FullMAC card with mode constraints: /sys/class/ieee80211/phy0/profile0/template0/mode # sta | /... # sta specific stuff | *->/profile1/template0/mode # rfmon | /... # rfmon specific stuff | *->/... # phy specific stuff virtual interface: /sys/class/ieee80211/sta0/parent # ->../phy0 /... card with two chips that share some phy resources: /sys/class/ieee80211/phy0/txpower # shared txpower /... /sys/class/ieee80211/phy1/parent # ->../phy0 /channel # independent /... /sys/class/ieee80211/phy2/parent # ->../phy0 /channel # independent /... Feyd - 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: wireless: recap of current issues (configuration)
On Fri, 2006-01-13 at 17:19 -0500, John W. Linville wrote: > Configuration > = > > Configuration seems to be coalescing around netlink. Among other > things, this technology provides for muliticast requests and > asynchronous event notification. > > The kernel should provide generic handlers for netlink > configuraion messages, and there should be a per-device 80211_ops > (wireless_ops? akin to ethtool_ops) structure for drivers to > populate appropriately. One other thing: capability. It's not enough to be able to configure the device, user-space tools also have to know what the device is capable of before they try touching it. Ie, which ciphers, protocols, channels, etc. Similar to the IWRANGE ioctl that there is now. Half the problem now is that you can't reliably tell what drivers support which features, or how much they support a particular feature. Think of ethernet devices and whether or not they support carrier detection, there's absolutely no way to tell that now (unless they respond to ethtool or MII, and some cards freeze if you touch them with MII too often). 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: wireless: recap of current issues (configuration)
Stuffed Crust wrote: The hardware knows what frequencies it supports. Unfortunately this has to be a somewhat dynamic thing, as this is often not queryable until the device firmware is up and running. This can be accomplished by passing a static table to the register_wiphy_device() call (or perhaps via a struct wiphy_dev parameter) or through a more explicit, dynamic interface like: wiphy_register_supported_frequency(hw, 2412). For completely programmable hardware, the stack should interact with a module like ieee80211_geo, to help ensure the hardware stays within legal limits. Jeff - 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: wireless: recap of current issues (configuration)
Johannes Berg <[EMAIL PROTECTED]> writes: > Yeah, this is about what I thought of -- and it makes me wonder if the > stack really should be aware of the channelization, or if the WiPHY > driver might better just handle it itself. The latter, possibly using library functions from the stack :-) -- Krzysztof Halasa - 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: wireless: recap of current issues (configuration)
On Fri, 13 Jan 2006, John W. Linville wrote: > Configuration > = > > At init, physical devices should be represented by a "WiPHY" device, > not directly by a net_device. The list of physical devices should > be discoverable through netlink and/or sysfs. (A WiPHY device is an > abstraction representing the radio interface itself.) I would suggest to start a level below, and have a WLAN device abstraction for a device connected to a bus. Conceptually this is an extension of the Linux device struct. This WLAN devices could have one or more WiPHY subdevices. A simple driver would have one WiPHY subdevice per RF transceiver. A complex driver could virtualize the RF transceiver and would allow to have dynamically created and removed WiPHY subdevices. In the standard case there will be only one WiPHY subdevice per WLAN device. > Virtual wlan devices should be associated to a WiPHY device many-to-one > (one-to-one for some devices). Virtual devices correspond to a net_device. May I suggest here to call this virtual devices interfaces. But I will continue to use your terminology. > Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon, > raw?, other modes?) which defines its "on the air" behaviour. Should > this mode be fixed when the wlan device is created? Or something > that can be changed when the net_device is down? The net_device status should be independent from the WLAN MAC virtual device status. Reassociations for a moving WLAN device are a good example. I could even emagine to switch modes for an active net_device, as long the MAC address doesn't change, you should do be able to do everything at the MAC level. > It may be necessary to remove, suspend, and/or disable wlan devices > in order to add, resume, and/or enable other types of wlan devices > on the same WiPHY device (especialy true for rfmon). A mechanism is > needed for drivers to be able to influence or disallow combinations > of wlan devices in accordance with capabilities of the hardware. Yes virtual devices should be dynamically creatable and removable. I can't see, why a RFMON virtual device and its memory structures should be created, if in most cases it will not be used. Otherwise I would start with the assumption, that there are no dependencies between devices. Configuration of devices should be orthogonal. They one problem I can see is scanning over several frequencies. If two virtual devices are doing this at the same time, we have a conflict. Maybe each WiPHY would have only one active interface, which would allow the virtual device scanning over multiple frequencies and a number of passive interfaces, which don't allow to change frequencies. More than one WiPHy subdevice will be required, if two virtual devices want to do scanning. > Do "global" config requests go to any associated wlan device? > Or must they be directed to the WiPHY device? Does it matter? > I think we should require "global" configuration to target the WiPHY > device, while "local" configuration remains with the wlan device. > (I'm not sure how important this point is?) Either way, the WiPHY > device will need some way to be able to reject configuration requests > that are incompatible among its associated wlan devices. Since the > wlan interface implementations should not be device specific, perhaps > the 802.11 stack can be smart enough to filter-out most conflicting > config requests before they get to the WiPHY device? Maybe the active and passive interface concept could help here. I don't think, that the upper layer should filter conflicts, because this code must make assumptions about the capabilities of lower layer components. If these assumptions are wrong, the upper layer code must be changed. If there is a configuration, which can't be supported, the component configured should just say no. -- Ulrich Kunitz - [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: wireless: recap of current issues (configuration)
On Fri, 2006-01-13 at 20:17 -0500, Stuffed Crust wrote: > If you're talking about the former.. things get quite complicated, but > that could be handled by having two WiPHY devices registered. The former; and yes, I thought about that too -- having a driver that shows two physical WiPHY devices as a single logical WiPHY device and distributes virtual devices among them... > As for the latter, when you factor in the needs of 802.11d and its > dependents (802.11j, 802.11k, and others) the stack is going to need to > be aware of the available channel sets; both in the sense of hardware > support and also the various regulatory requirements. > > The hardware knows what frequencies it supports. Unfortunately this has > to be a somewhat dynamic thing, as this is often not queryable until the > device firmware is up and running. > > This can be accomplished by passing a static table to the > register_wiphy_device() call (or perhaps via a struct wiphy_dev > parameter) or through a more explicit, dynamic interface like: > > wiphy_register_supported_frequency(hw, 2412). Yeah, this is about what I thought of -- and it makes me wonder if the stack really should be aware of the channelization, or if the WiPHY driver might better just handle it itself. johannes signature.asc Description: This is a digitally signed message part
Re: wireless: recap of current issues (configuration)
On Fri, Jan 13, 2006 at 11:32:02PM +0100, Johannes Berg wrote: > I'm not sure this is worth it. While putting this into the WiPHY device > creates more logic there, putting knowledge like 'how many different > channels can this WiPHY device support' etc. into some representation > that can be used by the stack to decide is much more trouble than it is > worth. Do you mean 'simultaneous' channel operation, or something more mundane like simply 'what frequencies can I run on'? If you're talking about the former.. things get quite complicated, but that could be handled by having two WiPHY devices registered. As for the latter, when you factor in the needs of 802.11d and its dependents (802.11j, 802.11k, and others) the stack is going to need to be aware of the available channel sets; both in the sense of hardware support and also the various regulatory requirements. The hardware knows what frequencies it supports. Unfortunately this has to be a somewhat dynamic thing, as this is often not queryable until the device firmware is up and running. This can be accomplished by passing a static table to the register_wiphy_device() call (or perhaps via a struct wiphy_dev parameter) or through a more explicit, dynamic interface like: wiphy_register_supported_frequency(hw, 2412). - Solomon -- Solomon Peachy ICQ: 1318344 Melbourne, FL Quidquid latine dictum sit, altum viditur. pgppjT3ppZOAb.pgp Description: PGP signature
Re: wireless: recap of current issues (configuration)
"John W. Linville" <[EMAIL PROTECTED]> writes: > Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon, > raw?, other modes?) which defines its "on the air" behaviour. Should > this mode be fixed when the wlan device is created? I think so. If needed one can delete and create. > Or something > that can be changed when the net_device is down? IMHO: unnecessary complicates things. > It may be necessary to remove, suspend, and/or disable wlan devices > in order to add, resume, and/or enable other types of wlan devices > on the same WiPHY device (especialy true for rfmon). A mechanism is > needed for drivers to be able to influence or disallow combinations > of wlan devices in accordance with capabilities of the hardware. If the control messages go through the main (WiPHY) driver it can decide and/or forward the request further, to the library. Not sure about netlink. OTOH I'm at all not sure netlink should be used for configuration. sysfs, ioctl seem a better options. Netlink is better for state monitoring etc. I don't know it very well though. > Do "global" config requests go to any associated wlan device? Are they any global config settings? sysctl or sysfs maybe? > Or must they be directed to the WiPHY device? Does it matter? If you mean "settings for a particular physical card" then WiPHY. > I think we should require "global" configuration to target the WiPHY > device, while "local" configuration remains with the wlan device. If "local" means "concerning the wlan device" then sure, yes. > (I'm not sure how important this point is?) Either way, the WiPHY > device will need some way to be able to reject configuration requests > that are incompatible among its associated wlan devices. Since the > wlan interface implementations should not be device specific, perhaps > the 802.11 stack can be smart enough to filter-out most conflicting > config requests before they get to the WiPHY device? I don't think so. The hardware driver should get the request first, the rest should look like a library. I've played with both approaches for years and I would avoid "802.11 using the hw driver" scenario if at all possible. -- Krzysztof Halasa - 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: wireless: recap of current issues (configuration)
[since none our replies made it to the lists, here mine are again. apologies to those who see it twice, just skip it, I only pasted my previous replies] > Virtual devices will have a mode (e.g. station, AP, WDS, ad-hoc, rfmon, > raw?, other modes?) which defines its "on the air" behaviour. Should > this mode be fixed when the wlan device is created? Or something > that can be changed when the net_device is down? IMHO there's not much point in allowing changes. I have a feeling that might create icky issues you don't want to have to tackle when the solution is easy by just not allowing it. Part of my thinking is that different virtual types have different structures associated, so changing it needs re-creating structures anyway. And different virtual device types might even be provided by different kernel modules so you don't carry around AP mode if you don't need it. > Do "global" config requests go to any associated wlan device? > Or must they be directed to the WiPHY device? Does it matter? > I think we should require "global" configuration to target the WiPHY > device, while "local" configuration remains with the wlan device. > (I'm not sure how important this point is?) Right [global config targets wiphy]. I do think this is an important UI issue that userspace will have to tackle, but I think the correct way for the kernel is to surface this issue instead of creating workarounds. > Either way, the WiPHY > device will need some way to be able to reject configuration requests > that are incompatible among its associated wlan devices. Since the > wlan interface implementations should not be device specific, perhaps > the 802.11 stack can be smart enough to filter-out most conflicting > config requests before they get to the WiPHY device? I'm not sure this is worth it. While putting this into the WiPHY device creates more logic there, putting knowledge like 'how many different channels can this WiPHY device support' etc. into some representation that can be used by the stack to decide is much more trouble than it is worth. johannes signature.asc Description: This is a digitally signed message part
