* wpa_supplicant and driver reload
@ 2013-12-11 9:02 Arend van Spriel
2013-12-15 5:46 ` Jouni Malinen
0 siblings, 1 reply; 5+ messages in thread
From: Arend van Spriel @ 2013-12-11 9:02 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless@vger.kernel.org
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: wpa_supplicant and driver reload
2013-12-11 9:02 wpa_supplicant and driver reload Arend van Spriel
@ 2013-12-15 5:46 ` Jouni Malinen
2013-12-15 9:15 ` Arend van Spriel
0 siblings, 1 reply; 5+ messages in thread
From: Jouni Malinen @ 2013-12-15 5:46 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless@vger.kernel.org
On 11 Dec 2013, at 1:02 am, Arend van Spriel <arend@broadcom.com> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: wpa_supplicant and driver reload
2013-12-15 5:46 ` Jouni Malinen
@ 2013-12-15 9:15 ` Arend van Spriel
2014-01-14 15:48 ` Arend van Spriel
0 siblings, 1 reply; 5+ messages in thread
From: Arend van Spriel @ 2013-12-15 9:15 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless@vger.kernel.org
On 12/15/2013 06:46 AM, Jouni Malinen wrote:
>
> On 11 Dec 2013, at 1:02 am, Arend van Spriel <arend@broadcom.com> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: wpa_supplicant and driver reload
2013-12-15 9:15 ` Arend van Spriel
@ 2014-01-14 15:48 ` Arend van Spriel
2014-01-14 16:30 ` Jouni Malinen
0 siblings, 1 reply; 5+ messages in thread
From: Arend van Spriel @ 2014-01-14 15:48 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless@vger.kernel.org
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 <arend@broadcom.com> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: wpa_supplicant and driver reload
2014-01-14 15:48 ` Arend van Spriel
@ 2014-01-14 16:30 ` Jouni Malinen
0 siblings, 0 replies; 5+ messages in thread
From: Jouni Malinen @ 2014-01-14 16:30 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless@vger.kernel.org
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2014-01-14 16:30 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-11 9:02 wpa_supplicant and driver reload Arend van Spriel
2013-12-15 5:46 ` Jouni Malinen
2013-12-15 9:15 ` Arend van Spriel
2014-01-14 15:48 ` Arend van Spriel
2014-01-14 16:30 ` Jouni Malinen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).