On Fri, Mar 24, 2006 at 11:05:02AM -0600, James Ketrenos wrote: > Since the scan results are supposed to report networks found; the first > agreement we need to make between user space and the kernel is how we > define a 'network', and how do we determine when a network has been > updated?
Whenever a frame for matching BSSID is received(?) > A direct scan for 'Bar' is sent, and the following is found via probe > request: > ssid_len=3, ssid=Bar, channel 1, BSSID: 00:0e:de:ad:be:ef > and via beacons: > ssid_len=3, ssid=Foo, channel 1, BSSID: 00:0e:de:ad:be:ef > > The network Bar is associated with, and time passes with no data or > probe requests being sent (idle network). Beacons are received for Foo, > but nothing for Bar (since the AP isn't beaconing hidden networks). > > Aside from the probe response for Bar, there are never any beacons that > indicate that the network Bar still exists. Scan results *should* > display Foo and Bar, but the current ieee80211 subsystem will filter out > Bar once 15s has passed without receiving a probe response. Yes, I would like to see both Foo and Bar being reported to user space and neither should be timed out as long as Beacon frames are received for the shared BSSID. > Currently ieee80211 does not differentiate between probe responses and > beacons for collecting network data. To "fix" the problem we have now, > ieee80211 needs to be changed to be able to distinguish between probe > respones and beacons, and update all networks that match channel and MAC > when a beacon is received (regardless of SSID) and update a specific > network if the frame is a probe response. Agreed. > Ideally user space should just register to receive all beacons and probe > responses from the network device and do all the parsing and network > management, with a timing interval specified for frequency to receive > beacons/probe responses that have not changed (although one packet every > 100ms isn't likely to cause too much thrash) > Exporting the entire frame allows user space to provide information on > 802.11h, 802.11e, 802.11i and other network capabilities that currently > aren't exposed via the wireless extension interface. This is something I would like to see happening at least as an option. It would be useful to be able to replace all management frame processing by user space mechanism. This is exactly what hostapd does for AP mode with Host AP driver and Devicescape 802.11 code. Similar mechanism would be nice to have for client mode. Timing requirements for 802.11 management frames are not too strict (with a potential exception with Probe Response, but even that seems to work quite well on Linux when done from user space), so they can be easily handled in user space. Implementing things like 802.11r will be quite a bit easier if both the management frames (authentication, association) and EAPOL frames can be taken care of by the same component. Otherwise, large number of new kernel <-> user space interfaces will be needed for adding IEs and interacting with roaming and association. > Doing this also has the advantage of being able to remove all scan and > network collection logistics out of the kernel and into user space. Agreed. -- Jouni Malinen PGP 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
