For the memory issues -- it looks like other functions that declare
the params on the stack free whatever they are working with by
themselves. Would you rather see this also done for the mac_addr
member, or factoring the cleanup minus the freeing of the whole params
struct into a separate function (which will then mean the
wpa_scan_free_params function just calls this cleanup function, and
then os_free on the struct itself)?
> > @@ -169,7 +195,9 @@ static void wpas_trigger_scan_cb(struct wpa_radio_work *work, int deinit)
> > return;
> > }
> >
> > - if (wpas_update_random_addr_disassoc(wpa_s) < 0) {
> > + if (wpa_s->mac_addr_rand_enable & MAC_ADDR_RAND_SCAN)
> > + wpa_setup_mac_addr_rand_params(params, wpa_s->mac_addr_scan);
> > + else if (wpas_update_random_addr_disassoc(wpa_s) < 0) {
>
> What is this trying to do and why? The commit message seems to imply
> that this should not have any changes in behavior, but this looks like a
> potential change.
Both of these are employing MAC address randomization in different
ways. I can make it so we try both here, but as far as I can tell,
since this implementation asks the driver to randomize the address
per-probe then if it is active it will take priority over the existing
implementation anyway. Now that you point this out, though, we could
set this bit even if the driver or module doesn't actually support the
hardware random MAC implementation, so it's probably worth doing both
here instead.
I am not sure if this is why the hwsim test breaks but I will investigate.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
