Thanks all for the follow-up on the 12/5 notes. Alan, Anurag, Michael
and I continued the conversation this morning; notes below.
-renee
* Follow-up on marking certain objects read-only: for now, we'll go with
solution Renee is implementing which adds a read-only property to NCUs.
The property will default to false. Upon commit or destroy, the property
will be checked; if it is true, the operation will fail unless the caller
has passed in a special override flag. When it creates NCUs for the
automatic NCP, nwamd will mark them read-only; thus the user will be able
to view but not change that NCP via the UIs. nwamd will use the override
flag in order to modify the automatic NCP as needed.
Once Renee has pushed these changes (this week), Anurag will update
nwamcfg to check the read-only property, and disallow the set and clear
commands on NCUs for which it is true.
* WLAN handling. Many issues here:
- Current 'known wlans' list vs. per-ncu preferences
The current implementation has a global list of all wlans that have
been connected to; what might be more useful is a per-wireless-link
prioritized list of what wlans the user wants this particular link
to connect to. This is a feature we will look at adding post-phase-1.
- 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 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?
General agreement that the behavior should be the same, and should be
analogous to the case where the user makes a change via ifconfig: nwam
should not interfere with, and possibly react to the change (if the new
wlan causes a different location to be activated, for example); but the
change will not affect stored profiles, and thus will be undone on
restart of the nwam service. But is the known wlan list a profile? It
does not seem unreasonable to expect that making the connection manually
should cause nwam to remember the wlan, just as it would if the choice
were made via the gui. Conclusion: the known wlan list should be updated
if a manual connection is made via dladm.
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.
