Hi Alan, Alan Maguire wrote: > I've been thinking a little more about the libnwam API > requirements for information about WiFi networks > visited - currently stored in the /etc/nwam/known_wifi_nets > file. It seems to me that as well as storing ESSID, we need > to have a format which supports addition of BSSID information > in the future (since at present BSSID info is ignored in connect > requests), and supports a prioritization of the visited wifi > networks (see p13 of the NWAM GUI spec - "Connection > Properties : Wireless") via "up" and "down" buttons.
So just to be clear, are we talking about being able to do the following: 1) Prioritise based of ESSID - which is what is in the UI spec for P1 and 2) For a given ESSID, allow you to prioritise the base station using BSSID Is that right? > > With these facts in mind, I suggest we go with a similar > object model to that used for NCUs, ENMs and locations > whereby a given object (a WLAN in this case) has a > set of associated properties. In the case of a WLAN, > at present we'll store a list of visited BSSIDs (which > may be used in the future) and a priority. It make > make sense to record other information too such > as the security mode (WEP, WPA or none) for a > hidden WLAN (I don't think this is available on scan, > but if the user specifies it once it could be stored). Is it possible for a given ESSID to have it available as both wep and wpa? > > So the basic API functions would be: > > nwam_error_t nwam_known_ap_create(const char *essid, > nwam_known_ap_handle_t *aphp); > nwam_error_t nwam_known_ap_read(const char *essid, > nwam_known_ap_handle_t *aphp); > nwam_error_t nwam_known_ap_commit(nwam_known_ap_handle_t aph); > nwam_error_t nwam_known_ap_destroy(nwam_known_ap_handle_t aph); > nwam_error_t nwam_walk_known_aps(int(*cb)(nwam_known_ap_handle_t, void *), > void *data, uint64_t flags, int *retp); > nwam_error_t nwam_known_ap_set_prop_value(nwam_known_ap_handle_t aph, > const char *prop, nwam_value_t value); > nwam_error_t nwam_known_ap_get_prop_value(nwam_known_ap_handle_t aph, > const char *prop, nwam_value_t *valuep); > > We could build simpler functions on top of these along the > lines of what Jim had for phase 0.5, but I think it might > make sense to go this way to allow association of multiple > properties (such as visited BSSID list, priority, etc) with a > visited WLAN name. What do people think? I'm happy enough with that, we don't need exactly the same API as Jim had, just as long as it's possible... So there will be a list of properties for each wifi net? This isn't unlike what we have in the API in the UI itself - just that right now the properties are not lists in our API. Thanks, Darren.
