[PATCH 2/3] Added notifications about chenges in BBSIDs list

Dan Williams dcbw at redhat.com
Tue Nov 10 01:25:32 EST 2009


On Mon, 2009-11-09 at 20:46 +0200, Jouni Malinen wrote:
> On Sun, Oct 18, 2009 at 03:56:02AM +0200, Witold Sowa wrote:
> > If scan results introduces new BSSs or discards some previously known,
> > new wpas_notify_bss_added or wpas_notify_bss_removed notifications are
> > called
> 
> >  int wpa_supplicant_get_scan_results(struct wpa_supplicant *wpa_s)
> >  {
> >  	int ret;
> > +	struct wpa_scan_results *prev_scan_res = wpa_s->scan_res;
> >  
> > -	wpa_scan_results_free(wpa_s->scan_res);
> > @@ -1681,6 +1711,8 @@ int wpa_supplicant_get_scan_results(struct wpa_supplicant *wpa_s)
> > +	notify_about_bssid_chenges(wpa_s, prev_scan_res, wpa_s->scan_res);
> > +	wpa_scan_results_free(prev_scan_res);
> 
> While I understand the desire for getting BSS added/removed
> notifications, the proposed change here is unfortunately introducing
> possibility for increased memory use by keeping two full sets of scan
> results in memory at the same time. In some cases, this can potentially
> increase the memory use by something like 128 kB (the limit used with
> WEXT; could potentially be even more) which is not really desired in
> number of embedded use cases for wpa_supplicant.
> 
> It looks like the only information used from the old scan results is the
> BSSID. I would assume it would be possible to create a smaller table of
> old BSSIDs from the old results, free the old results, fetch the new
> results, and compare the new results to the list of previously known
> BSSIDs instead. This should reduce the worst case memory use quite a
> bit.

Yeah, I think that's what we'd discussed at the wireless summit.  The
only thing we really need to do is reconstruct the object paths of the
AP objects (which depend on the BSSID currently but in reality are
opaque pointers and their format should be depended on) so that we can
emit the added/chagned stuff.  I'll poke around and resubmit the patch
if wsowa doesn't get around to it first.

Dan




More information about the HostAP mailing list