> Yes, that's a good idea. There are some more scenarios where > different roaming algorithms might make sense. However, I'm > still not sure where the roaming decision should be made (and > thus where the algorithm should be implemented). In user space > (wpa_supplicant) or in mac80211. Having it in user space would > allow non-mac80211-drivers to benefit too but the driver would > have to provide the necessary information. User-space is often easier to change *) However, if you want to use beacon-information, then user-space doesn't spring to my mind so quickly. Beacons come in quite fast, and I'd if I have to transport all of this to user-space ... Or we divide it: if user-spaces tells the kernel, then the kernel maintains a bss-list and whenever the kernel modifies the list "considerably", kernel pushes a nl80211 message to user-space, notifying it about the new state "once in a while". Then data gathering is in kernel, but decision making is in user-space. However, we need a good defintion for "considerably" and "once in a while", thought :-) *) EXCEPT if we're talking wpa_supplicant. Not everyone find wpa_supplicant easy to modify, because of the number of interwoven state-machines and handled corner-cases. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html