hi Darren Darren Kenny wrote: > 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? > > Only 1) above actually. This data model assumes that all properties (including priority) are common to all networks sharing a given ESSID, which is an important caveat I should have made clearer - sorry. >> 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? > > I'd say it's unlikely, although what we've been calling the "linksys" problem - where a bunch of wireless routers which are actually for distinct WLANs (as opposed to a set of base stations comprising an extended service area) - could apply I suppose. In other words, your wireless router uses WEP while your neighbour uses WPA, and both are called "linksys". >> 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. > > Yep, that's the idea. Thanks!
Alan
