Re: SIOCSIWESSID + SIOCSIWAP behaviour
On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote: On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote: When SIWESSID happens, softmac drops association/authentication with the current network and then starts a scan for the requested SSID. When found, softmac authenticates and associates to that network. I don't think there is requirement for doing a new scan here if recent scan results are available. When SIWAP happens, softmac drops association/authentication with the current network and then starts a scan for the requested BSSID. When found, softmac authenticates and associates to that network. Same here. Neither of these commands should drop IEEE 802.11 authentication. I would say that neither should drop association either until a new association is available or it is clear that current configuration does not allow association to be created. First case would just report a new association (no disassociation reported) and second case would report disassociation to user space. Right now, wpa_supplicant does SIWESSID and SIWAP in quick succession, which causes softmac to associate twice, and that quickly confuses things. (I don't really understand why wpa_supplicant uses SIWAP when a BSSID isn't specified in the config file, but...) There are two different modes and what is being described here is ap_scan=1, i.e., wpa_supplicant being responsible for requesting scanning and selecting an AP. In this mode, it is actually assumed that the driver does not do extra scans with SIWAP or SIWESSID. wpa_supplicant is telling the driver which channel (SIOCSIWFREQ), SSID, and BSSID to use. In the other mode, ap_scan=2, wpa_supplicant is only configuring the SSID and requesting the driver (or well, kernel side 802.11 management code) to figure out which AP to use. -- Jouni MalinenPGP id EFC895FA - 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: SIOCSIWESSID + SIOCSIWAP behaviour
On Mon, 2006-05-15 at 06:16 -0700, Jouni Malinen wrote: On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote: On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote: When SIWESSID happens, softmac drops association/authentication with the current network and then starts a scan for the requested SSID. When found, softmac authenticates and associates to that network. I don't think there is requirement for doing a new scan here if recent scan results are available. Yeah, thought that was understood. No reason to do another scan if you just did one in the driver 5 seconds ago. When SIWAP happens, softmac drops association/authentication with the current network and then starts a scan for the requested BSSID. When found, softmac authenticates and associates to that network. Same here. Neither of these commands should drop IEEE 802.11 authentication. I would say that neither should drop association either until a new association is available or it is clear that current configuration does not allow association to be created. First case would I assume that by or it is clear that the current configuration does not allow association to be created means that the driver cannot find an AP matching both the ESSID and the BSSID the user set, right? If so, then quite correct, the driver shouldn't disassociate until it's certain that the current user-specified configuration (ie, any combination of ESSID and BSSID set) does not apply to any known access points in the scan list. It's perfectly legal to send a new SIWAP event with a different BSSID if the driver simply associates with a new access point in the same ESSID too. In this case, the driver does _not_ need to send a blank SIWAP disassoc event to userspace, since it's staying within the same ESSID. I think at this point I'm still still assuming that APs with the same ESSID are on the same network by default. Although that's not entirely valid, especially in the realm of consumer gear (multiple 'linksys' APs on the same channel even, each with different upstream connection), in this case the user space application will have to know to lock the BSSID of the card/driver to the one it wants. That's a user space issue, not a driver issue. Driver's shouldn't be too smart about this stuff without providing standard overrides. configuration does not allow association to be created. First case would just report a new association (no disassociation reported) and second case would report disassociation to user space. If no association has been completed yet before the user sets SIWESSID or SIWAP, then of course no disassociation event needs to get sent to userspace because there's been no association from which to disassociate. I believe the following sequence is correct: boot user app issues SIWESSID 'foo' driver finds associates/authenticates to 'foo' (if not available, it Just Does Nothing) (if available, sends SIWAP of 'whatever foo is' to userspace) user app issues SIWAP '12:34:56:78:91:23' driver sends SIWAP of 00:00:00:00:00:00 (disassoc) to userspace driver finds and associates with '12:34:56:78:91:23' (if not available, it Just Does Nothing) (if available, sends SIWAP of '12:34:56:78:91:23' to userspace) Similarly, I believe the following is correct: boot user app issues SIWESSID 'foo' driver searches for 'foo' but does not find it (if driver does background scanning and finds 'foo', it may associate) (if driver does not do background scanning, must wait until user app requests a scan, and if 'foo' is in results, may associate) user app issues SIWAP '12:34:56:78:91:23' (no SIWAP driver disassoc event needed because no association exists) driver finds and associates with '12:34:56:78:91:23' (if not available, it Just Does Nothing) (if available, sends SIWAP of '12:34:56:78:91:23' to userspace) 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: SIOCSIWESSID + SIOCSIWAP behaviour
On Sun, May 14, 2006 at 11:29:38PM -0400, Dan Williams wrote: On Mon, 2006-05-15 at 00:29 +0100, Daniel Drake wrote: Hi Jean, Hi, Nice discussion you got going here ;-) I'd just like to check my understanding (and softmacs implementation) of SIWESSID and SIWAP behaviour, for managed mode. When SIWESSID happens, softmac drops association/authentication with the current network and then starts a scan for the requested SSID. When found, softmac authenticates and associates to that network. When SIWAP happens, softmac drops association/authentication with the current network and then starts a scan for the requested BSSID. When found, softmac authenticates and associates to that network. I'll chime in too... My understanding of WE is that your understanding of WE is correct. Yes. There is one case where you don't need to reassociate : if you already have the correct ESSID or BSSID. This mostly happens when you set the ESSID to any or the BSSID to off or any. Also, Jouni is correct that you don't need to scan if your scan results are fresh enough. But if the user has already set the SSID and _then_ sets the BSSID, the driver must attempt to associate with an AP that has _both_ those properties. Setting one doesn't cancel the other out (Jean, correct if I'm wrong here?) Correct. AFAIK, you can actually set any old BSSID you like on the access point, so there's no guarantee that the BSSID any access point advertises is unique. Furthermore I believe you can have one AP with one BSSID server more than one ESSID. Higher-end Cisco/3Com/etc products allow this. I believe the BSSID has to be unique. HP APs can also offer multiple ESSID for the same BSSID, but they do so using different BSSID. If you look at the 802.11 spec, I can't see how two different virtual cells can have the same BSSID, because the BSSID is the only thing that identify the cell (the ESSID is not in each packet). Is it correct that SIWAP can legally select *any* AP? (As opposed to only being for selecting a specific AP *on the ESS* indicated by a past or future SIWESSID call) Correct. The user may SIWAP _any_ BSSID at all, not necessarily related to the SSID. However, if the user just set an ESSID with SIWESSID, I'm fairly sure that ESSID must be honored as well. The main configuration is SIWESSID, that's the only config that is required by the standard. WIWAP is only a secondary configuration, that is optional and not supported in all drivers. The ESSID set should always be respected. If an ESSID is set, SIWAP should only look within APs having this ESSID, and not use a different ESSID. Only if the ESSID is set to 'any' should the card really pick any AP regardless of ESSID. Personally, I think that SIWAP is too tricky to use properly for most users, so we should encourage them to not use it. No matter how I think of it, this strikes me as a hard interface to implement. Because association isn't an atomic operation, it is tricky to get the sequencing right, e.g. if the user does SIWESSID to start association, and then SIWAP to select a different AP before the original association has completed. Hmm, what problems does this have? It's not really any different than if the user issues two SIWESSID calls in short sequence, so you have to handle the start assoc-disassoc-start assoc sequence anyway... I agree that it make things messy in the driver. I also agree that the user can do stupid things with iwconfig, and therefore there is no real difference. There is still a performance issue. Having to cancel and restart associations waste CPU cycles. One way to deal with that would be to improve the commit strategy of the Wireless API. Basically, every time you do a set, you schedule or reschedule the commit ioctl to happen in a few dozen ms. This way, you could bundle all the settting of apps such as wpa_supplicant with only a single commit. This is similar to the way the routing API works. But, you won't get away that end-users can do stupid stuff with iwconfig. Dan Have fun... Jean - 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: SIOCSIWESSID + SIOCSIWAP behaviour
On Mon, May 15, 2006 at 01:28:13PM -0700, Jean Tourrilhes wrote: I believe the BSSID has to be unique. HP APs can also offer multiple ESSID for the same BSSID, but they do so using different BSSID. If you look at the 802.11 spec, I can't see how two different virtual cells can have the same BSSID, because the BSSID is the only thing that identify the cell (the ESSID is not in each packet). What the standard says is somewhat irrelevant since there are APs that use multiple SSID with the same BSSID. I would say that it is reasonable for users to expect that this works with Linux, too. Personally, I think that SIWAP is too tricky to use properly for most users, so we should encourage them to not use it. Keep in mind that it is also used by some programs (e.g., wpa_supplicant in ap_scan=1) without the user having to know anything about that level of details.. There is still a performance issue. Having to cancel and restart associations waste CPU cycles. One way to deal with that would be to improve the commit strategy of the Wireless API. Basically, every time you do a set, you schedule or reschedule the commit ioctl to happen in a few dozen ms. This way, you could bundle all the settting of apps such as wpa_supplicant with only a single commit. This is similar to the way the routing API works. Number of drivers use an atomic associate command (usually, a private ioctl) with wpa_supplicant. If there were a standard way of doing that, it could be helpful. -- Jouni MalinenPGP id EFC895FA - 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: SIOCSIWESSID + SIOCSIWAP behaviour
On Mon, May 15, 2006 at 02:40:14PM -0700, Jouni Malinen wrote: On Mon, May 15, 2006 at 01:28:13PM -0700, Jean Tourrilhes wrote: I believe the BSSID has to be unique. HP APs can also offer multiple ESSID for the same BSSID, but they do so using different BSSID. If you look at the 802.11 spec, I can't see how two different virtual cells can have the same BSSID, because the BSSID is the only thing that identify the cell (the ESSID is not in each packet). What the standard says is somewhat irrelevant since there are APs that use multiple SSID with the same BSSID. I would say that it is reasonable for users to expect that this works with Linux, too. Yeah, I guess it's required when you are using standard client card, but using the same BSSID is not as clean. Personally, I think that SIWAP is too tricky to use properly for most users, so we should encourage them to not use it. Keep in mind that it is also used by some programs (e.g., wpa_supplicant in ap_scan=1) without the user having to know anything about that level of details.. My point is that we don't have to be perfect with respect to the end user through SIWAP. There is still a performance issue. Having to cancel and restart associations waste CPU cycles. One way to deal with that would be to improve the commit strategy of the Wireless API. Basically, every time you do a set, you schedule or reschedule the commit ioctl to happen in a few dozen ms. This way, you could bundle all the settting of apps such as wpa_supplicant with only a single commit. This is similar to the way the routing API works. Number of drivers use an atomic associate command (usually, a private ioctl) with wpa_supplicant. If there were a standard way of doing that, it could be helpful. My goal was to offer the commit mechanism to solve those issues. The basic plumbing is in place, so we just a slightly more clever commit mechanism. The advantage is that the mechanism is generic, so will work for anything. Jouni MalinenPGP id EFC895FA Jean - 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
SIOCSIWESSID + SIOCSIWAP behaviour
Hi Jean, I'd just like to check my understanding (and softmacs implementation) of SIWESSID and SIWAP behaviour, for managed mode. When SIWESSID happens, softmac drops association/authentication with the current network and then starts a scan for the requested SSID. When found, softmac authenticates and associates to that network. When SIWAP happens, softmac drops association/authentication with the current network and then starts a scan for the requested BSSID. When found, softmac authenticates and associates to that network. Is it correct that both of these immediately trigger deauthenication+deassocation then authentication+assocation? Is it correct that SIWAP can legally select *any* AP? (As opposed to only being for selecting a specific AP *on the ESS* indicated by a past or future SIWESSID call) Right now, wpa_supplicant does SIWESSID and SIWAP in quick succession, which causes softmac to associate twice, and that quickly confuses things. No matter how I think of it, this strikes me as a hard interface to implement. Because association isn't an atomic operation, it is tricky to get the sequencing right, e.g. if the user does SIWESSID to start association, and then SIWAP to select a different AP before the original association has completed. Any clarification appreciated. Thanks, Daniel - 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
