Alan Maguire wrote: > 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);
This would work well for us in the GUI - the main issue that I think is inconsistent though with the current UI spec is that using this API we get separate entries of ESSID/BSSID, even with the same ESSID - most user's don't really care about the BSSID - so it's unlikely we would show it, or even set it when adding a new entry a lot of the time. 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. 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? > > ...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? I think I expressed an interest in these functions before - the reason being that it's better for the GUI to be able to get the list of known APs from nwamd itself rather than instigating a scan itself by calling libdladm - especially at start up - this ensures that the user "sees" the same list as nwamd - which is always better if the user is likely to ask nwamd to connect to something. Saying that, if it's preferred that nwamd sends this to the UI in an event rather than adding a new set of API calls, then that's alright - just as log as we can trigger the event (rescan) and that on initial connection to nwamd the GUI receives sufficient events to be able to populate the GUI for the user - this is what Michael's original proposal was, but I'm really not sure if that still stands now. One useful piece of information that we get in the GUI from a rescan is whether the list has changed - i.e. the deScanSame or deScanChanged events - this tells us whether we need to update the GUI or not based on a scan event, is this information in Phase 1? Thanks, Darren.
