Renee Danson writes:
> - How much attention should we pay to BSSIDs?
> Jim's fix for 6773627 started us in the direction of paying less
> attention to BSSIDs; for now, we will stick with that behavior, as
> there's currently no point in specifying a BSSID on connect. The
> existing interfaces created in phase 0.5 will be integrated into the
> phase 1 library mostly as-is, as discussed in the follow-up from the
> 12/5 meeting.
> xxx my notes on this topic are very vague. if others who were part of
> the discussion can chime in with more detail here, that would be great!
What you *can* do with the current libdladm code is use BSSID to
determine on your own whether you want to try to connect or not, and
you can check after connecting whether the BSSID you get is any of the
ones you want (but other than disconnecting, you can't fix it).
What you cannot do is ask for a particular BSSID on connect. It just
doesn't work. If you use the NWAM-specific libdladm "don't scan on
connect" flag, then it just uses ESSID alone. If you don't use that
flag, then libdladm scans, and will not bother connecting if the BSSID
you request isn't in the list, but otherwise doesn't make any attempt
to connect to the specific BSSID you ask for.
On top of that, the 0.5 GUI doesn't really represent any of this
information, so, caught between a rock and a hard place, it's pretty
much pointless to try very hard at BSSID goodness. The best I think
we can do here is annoy users.
I don't really have any solutions here for NWAM Phase 1. The long
term would be to fix libdladm's wireless support so that it's a bit
less baroque (and much less bah-roken), but that very likely involves
work with the drivers as well. And then you'd need to find a way to
represent it in the GUI so that the information is *not* just
confusing.
> - What happens if the user connects to a wlan using dladm? Is the
> behavior different than it would be if a new wlan were selected via
> the gui interface?
For 0.5: yes and no. Connecting there still goes through the
BSSID-ignoring logic in libdladm, but it doesn't set the "please don't
scan" flag.
> were made via the gui. Conclusion: the known wlan list should be updated
> if a manual connection is made via dladm.
I certainly agree with that.
> An additional issue here is how we actually implement this; it's not
> clear that all wireless drivers have any sort of connection notifications.
> Some may use the IFF_RUNNING flag for this purpose; but it seems likely
> we'll need to do some polling. A long-term goal should be to move toward
> eliminating polling in favor of asynchronous notifications for the events
> nwamd cares about.
Indeed. The libdladm wireless subsystem needs to be redesigned.
Neither connect nor scan requests should block. Changes in state
should be sent as notifications to interested parties. In particular,
what I'd really like to see is:
- commands to send "Association request," "Reassociation request,"
"Disassociation," and "Probe request" messages.
- async reception of "Association response," "Reassociation
response," "Disassocation," and "Probe response" messages. It
would be nice to receive Beacons as well.
In other words, I think we'd be much better off here if we could get
lower-level access to the behavior of these devices.
(My understanding is that "Authentication" and "Deauthentication"
aren't interesting in a post-WEP world because the mechanism has
changed, but I haven't read that far in the standards ...)
--
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
