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
On 11 Dec 2013, at 1:02 am, Arend van Spriel <[email protected]> wrote:
> 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?
Yes, it can.
(Did you not try it before asking? Or did it fail in some way?)
- Jouni
On 12/15/2013 06:46 AM, Jouni Malinen wrote:
>
> On 11 Dec 2013, at 1:02 am, Arend van Spriel <[email protected]> wrote:
>
>> 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?
>
> 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
On Tue, Jan 14, 2014 at 04:48:44PM +0100, Arend van Spriel wrote:
> 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_supplicant requests a scheduled scan. I fixed that by
> resetting wpa_s->normal_scans to zero upon entering
> WPA_INTERFACE_DISABLED state.
Patch welcome..
> 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.
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.
--
Jouni Malinen PGP id EFC895FA
On 12/15/2013 10:15 AM, Arend van Spriel wrote:
> On 12/15/2013 06:46 AM, Jouni Malinen wrote:
>>
>> On 11 Dec 2013, at 1:02 am, Arend van Spriel <[email protected]> wrote:
>>
>>> 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?
>>
>> 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.
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