Darren Kenny writes: > This is a fairly general thing - and I'm not really sure how other platforms > handle the ESSID/BSSID combination, because really most users never even know > the BSSID - this can cause issues for example when roaming within a building > with the same ESSID but different BSSIDs - the user can end up being asked to > enter the key unnecessarily. Now maybe this is being fixed by Jim in 0.5 by > the > "nwamd should care less about bssids" bug, but I could be mistaken.
Yes, that's essentially what I fixed there. More precisely: I made it so that once a given AP is marked as "known" by a given non-empty ESSID, we assume that all APs with other BSSIDs that we encounter are similarly "known." The downside is that if you ever connect intentionally to that ubiquitous "linksys" node, then you may automatically connect to any such node named "linksys" in range, even though it may not be in any way related to the original one that you selected. > Even still I personally think nwamd does care too much about BSSID in > comparison > to other implementations for similar functionality... Maybe this would be a > configuration option? I have a tunable now in SMF for 0.5, but I'm not really sure what to do about this longer term. I think it'd be good if NWAM could somehow do some more "probing" of the network to try to verify that the identity of the network behind the newly-connected AP is more or less what we expect it to be, but I don't know how hard that might be to accomplish. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
