wpa_supplicant and driver reload
Hi Jouni,
A basic questionIn my testing I normally stop wpa_supplicant when reloading my driver and start it again, but I was wondering whether this is needed. Can wpa_supplicant deal with interface index change for the network interface?
Gr. AvS
Quoted 1 line · Arend van Spriel
A basic questionIn my testing I normally stop
wpa_supplicantwhen reloading my driver and start it again, but I was wondering whether this is needed. Canwpa_supplicantdeal with interface index change for the network interface?
Yes, it can.
(Did you not try it before asking? Or did it fail in some way?)
- Jouni
Quoted 8 lines · Jouni Malinen
Quoted 1 line · Arend van Spriel
A basic questionIn my testing I normally stop
wpa_supplicantwhen reloading my driver and start it again, but I was wondering whether this is needed. Canwpa_supplicantdeal with interface index change for the network interface?Yes, it can.
(Did you not try it before asking? Or did it fail in some way?)
It failed. On my Ubuntu machine it works fine, but it seems NetworkManager does give explicit RemoveInterface and CreateInterface dbus primitives. When running wpa_supplicant without NetworkManager it fails and it seems to be using the previous if_index. I will give another stare the wpa_s log and send it out when I can not make sense of it.
Regards,
Arend
Quoted 11 lines · Arend van Spriel
Quoted 10 lines · Jouni Malinen
Quoted 4 lines · Arend van Spriel
A basic questionIn my testing I normally stop
wpa_supplicantwhen reloading my driver and start it again, but I was wondering whether this is needed. Canwpa_supplicantdeal with interface index change for the network interface?Yes, it can.
Quoted 8 lines
Quoted 1 line
(Did you not try it before asking? Or did it fail in some way?)
It failed. On my Ubuntu machine it works fine, but it seems NetworkManager does give explicit RemoveInterface and CreateInterface dbus primitives. When running
wpa_supplicantwithout NetworkManager it fails and it seems to be using the previousif_index. I will give another stare thewpa_slog and send it out when I can not make sense of it.
Found the problem in the way brcmfmac does cleanup upon unload. With that fixed I notice some other behaviour. After 3 driver reloads (within 1 minute) wpa_supplicant requests a scheduled scan. I fixed that by resetting wpa_s->normal_scans to zero upon entering WPA_INTERFACE_DISABLED state. The only thing left is that after each reload the delay before requesting a scan increases with 1 second. This is caused by the fact that in wpa_supplicant_driver_init() the delay is determined by a static counter that increments upon each call (if there are enabled networks). I think this is mainly intended for wpa_s startup so scans for each interface are not colliding. Not sure what the best way is to solve that.
Regards,
Arend
Quoted 6 lines · Arend van Spriel
On 12/15/2013 10:15 AM, Arend van Spriel wrote:
Found the problem in the way brcmfmac does cleanup upon unload. With that fixed I notice some other behaviour. After 3 driver reloads (within 1 minute)wpa_supplicantrequests a scheduled scan. I fixed that by resettingwpa_s->normal_scansto zero upon enteringWPA_INTERFACE_DISABLEDstate.
Patch welcome..
Quoted 7 lines
The only thing left is that after each
reload the delay before requesting a scan increases with 1 second. This is caused by the fact that inwpa_supplicant_driver_init()the delay is determined by a static counter that increments upon each call (if there are enabled networks). I think this is mainly intended forwpa_sstartup so scans for each interface are not colliding. Not sure what the best way is to solve that.
Finishing this stalled discussion:
http://patchwork.ozlabs.org/patch/245486/
And yes, this was added very much for the case of initial start only, so doing a clean change to limit it for that case should be fine.
Signature · 1 line
Jouni Malinen PGP id EFC895FA