some comments below following up on the issues
raised in the discussion...
Renee Danson wrote:
> Anurag, Alan, Michael and I had a con call this morning, where we walked
> through some of the details of the phase 1 implementation. My notes are
> included below; additions/corrections/questions are welcome.
>
> -renee
>
>
> * Problem with Automatic IP NCUs: their only activation rule is that
> they should be activated if their underlying link is active; but that
> dependency/condition is implicit for *all* IP NCUs, so it would be
> confusing for that to show up here but not in user-created NCUs.
>
> Discussed whether or not activation mode was even needed for IP NCUs;
> is it sufficient just to specify the underlying link's activation mode?
>
> Conclusion: we will remove the activation mode and related properties
> from IP NCUs (i.e. these properties will become specific to link NCUs).
> Alan will include this with some other libnwam work he has in progress
> (removal of under property from all NCUs).
>
>
This is done in the latest changeset I just pushed this morning.
> * What should happen when new links are added to the system? The active
> NCP should reflect their availability (the user should not have to
> actually create a physical link NCU); but should the new link be enabled
> by default? Yes in the case of the automatic NCP; but what about the
> user NCP? We can imagine scenarios where the user made simple policy
> changes (ordering wired interfaces, for example), but still expects
> this sort of "automatic" behavior. On the other hand, this might not
> be what's wanted by someone who has an elaborate, customized NCP.
>
> One possibility would be to have either a template (default set of
> property values for new NCUs), which may be modified by the user; or
> maybe just a per-NCP property that says whether or not new links should
> be enabled by default.
>
> Conclusion: for now, new link NCUs will always be enabled, under the
> assumption that this is the "expected" behavior by users who haven't
> fiddled much with NCP configuration; users who *have* done so and might
> expect something different at least would know how to take corrective
> action if needed. Implementing one of the configuration knobs we
> discussed will be a post-phase 1 RFE.
>
>
In the latest changeset, ?enabled? defaults to true when
NCUs are created. At present physical link NCUs default
to the manual activation mode on creation. I think this
is fine for nwamcfg, since users of it will likely understand
how to manipulate activation mode to fit in with their
desired policy, but I wonder if we should have nwamd
try and fit created link NCUs (e.g. in hotplug insert scenarios)
into the existing policy for their NCP. A few simple heuristics
in nwamd might be all that is needed to help usability here -
if all other NCUs are prioritized/grouped in simple ways
(e.g. grouped into wired and wireless), we fit in with that
(but only if _all_ physical links are prioritized). If activation
modes of other links are manual, conditional or some
mixture of activation modes, we default to manual/enabled,
since there is no clear pattern to follow.
> * Per-NCP properties (one of the possible configuration knobs for the
> new-link question) would be more generally useful; an example is the
> need for a read-only property for the automatic NCP.
>
>
I was thinking about this for a bit, and I think it may make
more sense for now to do this sort of thing with a configuration
flag - on creation of NCUs in the automatic NCP, we?d pass in
a ?system? flag which sets a system property to true. The UI and
GUI can then use this value to determine that deletion or
modification of such objects should fail. nwamd would be the sole
entity that could manipulate such config. I think the automatic and
no-net locations would need this too (since these should be created
and modified by nwamd only) which is why I?d lean towards
doing this at the NCU level rather than at the NCP level - a common
approach - adding a ?system? boolean property - would work
for NCUs and locations.
> * GUI vs. CLI capabilities: what happens if the GUI, which deliberately
> attempts to simplify things for users who aren't trying to do complex
> things, loads a configuration created by the CLI which contains elements
> that it cannot represent?
>
> Conclusion: with the current (phase 1) set of options, we don't think
> this is a risk; but it's definitely something to think about as we start
> adding support for more advanced configurations.
>
> * WLAN list manipulation: The current phase 1 API does not include the
> ability to modify the list of known WLANs. In phase 0, this was possible,
> though it required editing the text file. In phase 0.5, the GUI allows
> you to modify the list, using some basic libnwam functions.
>
> We discussed making this list another library object, which would be
> operated on with a set of functions much like the existing objects.
> This would be a non-trivial addition to the phase 1 work.
>
> Another possibility might be to keep the existing interface, and look
> at updating after phase 1 is completed.
>
> In any case, we can't have a regression here: the user needs to be able
> to modify the list via the GUI.
>
I?ve been trying to figure out a way of pushing the known
wifi config data into the existing config model for NCUs, ENMs
and locations - i.e. .conf files in which each line consists of
a name followed by a set of property/type/values tuples. The
known wifi config doesn?t really fit this model, so I think
the best thing is to stick with the existing interfaces and backend
file format with some slight modifications for consistency with the
rest of phase 1 libnwam. Here is what I suggest:
nwam_error_t nwam_get_known_ap_list(nwam_known_ap_t *aps, uint t *nap);
void nwam_free_known_ap_list(nwam_known_ap_t *aps);
nwam_error_t nwam_add_known_ap(const char *essid, const char *bssid);
nwam_error_t nwam_delete_known_ap(const char *essid, const char *bssid);
nwam_error_t nwam_set_wlan_key(const char *essid, const char *bssid,
const char *secmode, const char *key);
...so bascially the phase 0.5 interfaces, but returning an
nwam_error_t to be consistent with the rest of the phase 1
libnwam. These functions would communicate with the
backend running in netcfgd via the doors interface
as the other phase 1 libnwam functions do. Does this seem
okay?
Also, the phase 0.5 libnwam API includes a few other
functions which we may need - a rescan trigger function
(libnwam_start_rescan()), wlan selection
(libnwam_select_wlan()). retrieval/freeing of most recent
cached wlan list (libnwam_get_wlan_list(),
libnwam_free_wlan_list()). Which of these, if any,
do we need for phase 1?
Alan
