wpa_supplicant / hostap changes

[Roy Marples]

Hi List

wpa_supplicant and hostap love to take an interface down, make changes and then
bring it up when ready to go.

Now, the Linux nl80211 stack doesn't seem to need this and from what I can tell,
neither does ours. Certainly from the wpa_supplicant side.

Sadly, all 3 of my NetBSD supported wifi devices don't do HostAP mode, so I
can't test that part of it. I have tested urtwm, iwi and iwn. Does anyhave have
any others, preferably hostap capable and test this patch please?

It's important for up-coming dhcpcd support for anonymous profiles.

Thanks

Roy

[Robert Elz]

I have an iwm interface I could test that with, I have no idea if
it is hostap capable or not, but given that you say iwi and iwn are
not, I would guess not also.

However, that paytch to wpa_supplicant sounds like it would be
wonderful for iwm users, as the iwm driver has some yet undiscovered
bug where every 1/(rand() % N + 1) (for some unknown, but not large, N)
times the interface should come up it "failed to load firmware" and fails.

While obviously not doing anything to fix whatever bug that is (something
about the iwm cpu states not being correct, it seems) not taking the
interface down and up without a really good reason would really help with
network stability (if I disable wpa_supplicant, and config the WiFi
manually, which I can do where no WPA security is being used, then the
interface typically runs for weeks without issues, with wpa_supplicant
running it is usually just days, sometimes hours, or less - which might
be related to DHCP lease times, I haven't checked).

So even though I am not likely to contribute much info to your request, I
am going to test the patch - unless it makes things worse, or fails to
work, expect to hear no more from me...

But thanks for this.

kre


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Robert Elz
I have an iwm interface I could test that with, I have no idea if
it is hostap capable or not, but given that you say iwi and iwn are
not, I would guess not also.
However, that paytch to wpa_supplicant sounds like it would be
wonderful for iwm users, as the iwm driver has some yet undiscovered
bug where every 1/(rand() % N + 1) (for some unknown, but not large, N)
times the interface should come up it "failed to load firmware" and fails.
While obviously not doing anything to fix whatever bug that is (something
about the iwm cpu states not being correct, it seems) not taking the
interface down and up without a really good reason would really help with
network stability (if I disable wpa_supplicant, and config the WiFi
manually, which I can do where no WPA security is being used, then the
interface typically runs for weeks without issues, with wpa_supplicant
running it is usually just days, sometimes hours, or less - which might
be related to DHCP lease times, I haven't checked).

I doubt if this change will address your issue :/

Post by Robert Elz
So even though I am not likely to contribute much info to your request, I
am going to test the patch - unless it makes things worse, or fails to
work, expect to hear no more from me...
But thanks for this.

Here's a v2 of the patch which merges the two different route(4) processing
blocks into one and gives hostapd exactly the same functionality of
wpa_supplicant re interface arrival and if up/down responsiveness. I wonder if
this was the reason why it manually brought the interface down/up in the first
place!

Roy

[Roy Marples]

Post by Roy Marples
Here's a v2 of the patch which merges the two different route(4) processing
blocks into one and gives hostapd exactly the same functionality of
wpa_supplicant re interface arrival and if up/down responsiveness. I wonder if
this was the reason why it manually brought the interface down/up in the first
place!

I've comitted this as a sequence of patches which I've sent upstream.
Also made a few more minor improvements.

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de