Re: SIOCGIWSCAN wireless event behaviour
On Thu, 2006-04-20 at 15:15 +0100, Daniel Drake wrote: Hi Jean, A query regarding wireless events: under which circumstances should a driver/stack send a SIOCGIWSCAN event to userspace? Should it be sent whenever a driver has new scan results available, or only when the user requested a scan a short time beforehand (via SIOCSIWSCAN)? Similar situation: when wpa_supplicant requests a scan, the driver scans and pushes the GIWSCAN at completion. _Every_ process (like NetworkManager) listening for netlink WE messages gets the GIWSCAN event even though only wpa_supplicant requested the original scan. So what I'm saying is that applications that process GIWSCAN netlink messages today should _already_ be able to handle random GIWSCAN events at any time even when they have not explicitly requested a scan with SIWSCAN. The events are broadcast and the driver shouldn't really care which user app initiated any particular request. Multiple apps can theoretically request scans at any time, though this isn't so good in practice. I ask this because softmac is sending the SIOCGIWSCAN event even when the user did not explicitly ask for it. Given the above, I think this behavior is fine and even desirable. I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant (but have not confirmed that yet). If this is the case, wpa_supplicant should not be getting confused by GIWSCAN events happening at random times, and should be fixed. However, in my experience with 0.4.8, this isn't a problem and wpa_supplicant handles random scan events correctly. Not sure about the 0.5.x branch though. 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: SIOCGIWSCAN wireless event behaviour
On Thu, Apr 20, 2006 at 03:15:59PM +0100, Daniel Drake wrote: I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant (but have not confirmed that yet). No, they don't. madwifi-ng is already doing this with background scanning and as was pointed out, there can be multiple programs asking for scans, so user space must be prepared for multiple events anyway. -- 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: SIOCGIWSCAN wireless event behaviour
On Thu, Apr 20, 2006 at 10:37:32AM -0400, Dan Williams wrote: On Thu, 2006-04-20 at 15:15 +0100, Daniel Drake wrote: Hi Jean, A query regarding wireless events: under which circumstances should a driver/stack send a SIOCGIWSCAN event to userspace? Should it be sent whenever a driver has new scan results available, or only when the user requested a scan a short time beforehand (via SIOCSIWSCAN)? The original behaviour was that the event was sent only when a user did request a scan. At that time, cards did not do background scanning, so new scan results would be produced only as a result of a user scan. After a short discussion we Dan, we agree that to change that, the driver should send a scan whenever a new scan result is available, regardless of how it happens (background scan or user scan). This allow smart application to synchronise on background scans and avoid them generating useless user scans. Minimising the number of user scan is actually good. Similar situation: when wpa_supplicant requests a scan, the driver scans and pushes the GIWSCAN at completion. _Every_ process (like NetworkManager) listening for netlink WE messages gets the GIWSCAN event even though only wpa_supplicant requested the original scan. So what I'm saying is that applications that process GIWSCAN netlink messages today should _already_ be able to handle random GIWSCAN events at any time even when they have not explicitly requested a scan with SIWSCAN. The events are broadcast and the driver shouldn't really care which user app initiated any particular request. Multiple apps can theoretically request scans at any time, though this isn't so good in practice. 100% correct. I ask this because softmac is sending the SIOCGIWSCAN event even when the user did not explicitly ask for it. Given the above, I think this behavior is fine and even desirable. Yes. I think the 'extra' SIOCGIWSCAN event may be confusing wpa_supplicant (but have not confirmed that yet). If this is the case, wpa_supplicant should not be getting confused by GIWSCAN events happening at random times, and should be fixed. However, in my experience with 0.4.8, this isn't a problem and wpa_supplicant handles random scan events correctly. Not sure about the 0.5.x branch though. After we changed to behaviour of ipw, various users reported that wpa_supplicant was confused. I particularly trust the report of Bill Moss, who has been hacking ipw for a long time : http://sourceforge.net/mailarchive/forum.php?thread_id=10091113forum_id=38938 Jouni was notified, but did not really answer to that bug report. Then, the ipw maintainers commited the following patch to ipw that fix or workaround that issue : http://marc.theaimsgroup.com/?l=linux-netdevm=114492056522667w=2 I would still like Jouni to have a look at the issue to tell us where the problem is. Two driver having issue is not coincidence. I would hate driver starting to implement various workaround if the problem is really in wpa_supplicant. 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: SIOCGIWSCAN wireless event behaviour
On Thu, Apr 20, 2006 at 09:43:54AM -0700, Jean Tourrilhes wrote: After we changed to behaviour of ipw, various users reported that wpa_supplicant was confused. I particularly trust the report of Bill Moss, who has been hacking ipw for a long time : http://sourceforge.net/mailarchive/forum.php?thread_id=10091113forum_id=38938 Hmm.. Can someone please describe what was changed? Just sending SIOCGIWSCAN events more frequently? I have not seen any problems with this in my tests (though, mainly with madwifi-ng). Is the broken case available in one of the kernel trees? 2.6.16? wireless-2.6? (i.e., where can I get the exact version of ipw2200 driver that is expected to show incorrect behavior)? Jouni was notified, but did not really answer to that bug report. Then, the ipw maintainers commited the following patch to ipw that fix or workaround that issue : http://marc.theaimsgroup.com/?l=linux-netdevm=114492056522667w=2 Hmm.. I don't remember having seen that report from Bill Moss.. How was I notified? ;-) The patch here seems to be moving ipw_disassociate() call, so it is not obviously clear from that what the impact on behavior is. I can try to reproduce this, but I would like to know what version to test with in order to avoid any possible workarounds from hiding the issue. -- 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: SIOCGIWSCAN wireless event behaviour
Jean Tourrilhes wrote: The original behaviour was that the event was sent only when a user did request a scan. At that time, cards did not do background scanning, so new scan results would be produced only as a result of a user scan. After a short discussion we Dan, we agree that to change that, the driver should send a scan whenever a new scan result is available, regardless of how it happens (background scan or user scan). This allow smart application to synchronise on background scans and avoid them generating useless user scans. Minimising the number of user scan is actually good. Thanks for all the responses. I am not sure if the 'extra' SIOCGIWSCAN event is what is causing wpa_supplicant's confusion, but the kind of behaviour I am seeing is wpa_supplicant associating to the network, immediately disassociating, and then associating again before the connection stabilises. This is with wpa_supplicant 0.5.2 connecting to an unencrypted network. I am also seeing that softmac reassociates with a network after wpa_supplicant exits. Johannes posted a softmac patch earlier which may help (related to softmac's handling of SIOCGIWAP). I will do some further investigation and provide a more complete report if that doesn't fix it. 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
