Wifi flakey, wpa_supplicant sometimes crashing

[humdinger]

This is hrev45525.

Since the recent keystore addition, connecting to wifi isn't working every time. Connecting via the NetworkStatus icon in the Deskbar works sometimes, sometimes it doesn't. Sometimes I get asked to give the wpa_supplicant access to the keystore ("Allow always"), sometimes not. Then, while connecting, the connection window with the already filled in password appears 3 times after another. I'm not sure if I should check the box "Store this configuration" or not...

Anyway, then often the wpa_supplicant crashes, see attached report plus syslog and syslog.old. Not sure how much of syslog.old is from that session. Is there a way to detect the start of the entries for the most recent session?

In this session, I tried to down/up/scan with ifconfig to make my network ("haiku-top") visible again in the NetworkStatus replicant and tried once more to connect. Same result.

[humdinger]

wpa_supplicant crash report

[humdinger]

syslog

[humdinger]

syslog.old

[streak]

The same symptoms are visible on my computer..

[Pete]

Having now been using WiFi for a couple of weeks, I thought I'd add my experiences.

I have an iprowifi4965, and initially had no luck connecting to my N-mode 150Mb/s router (ticket #9935), though Linux on the same laptop had no trouble. This was eventually solved by limiting the router to 65Mb/s (though again Linux has no difficulty with 150Mb). However, I'm still having much the same problems as described above. I do not have keystore enabled. (Not sure even how to do that -- it's present in my latest build, but it's never run.) I see much the same problems both on the new build (45851) and my older work system (44674).

The first thing I did to improve things was to discard using the NetworkStatus applet at all and remove it from the Deskbar. Trying to connect via that seemed to work sometimes but usually not. And when things went wrong (often!) it would lock up the Deskbar. ifconfig from the Terminal would sometimes lock up so hard ctrl-C wouldn't kill it and neither would ProcessMonitor 'Threads and Usage'. I now have a short xicon script that connects me reliably.

As others note, this only works the first time after boot. Attempts to disconnect and reconnect fail without exception. Sometimes it looks as if ifconfig is reporting a good link (" MTU: 1500, Metric: 0, up broadcast link auto-configured"), but there seems to be no actual connection to the network (e.g. ping fails). Other times I just see "configuring" for ever.

It also looks as if the initial configure at boot takes a strangely long time. In Linux, I see the "Connection Established" as soon as boot is finished, but in Haiku I have to wait for a few minutes of "configuring" before I can try to connect. [Of course Linux takes way longer to boot, so I suppose that might be related!]

I can only reliably connect to my own router if I am nearby. If I take my laptop into the garden, Linux still has no trouble automatically connecting, but -- even if I use the script, which tries to 'join' my net -- I end up being connected to "Thunderpussy" (:-)), which happens to be an open net (but with an entry password) at about the same strength as mine. Attempts to disconnect from that and join my own fail as above, of course. (If I connect indoors, and then take the running laptop into to the yard, the connection remains perfect.)

[diver]

Replying to Pete:

The first thing I did to improve things was to discard using the NetworkStatus applet at all and remove it from the Deskbar. Trying to connect via that seemed to work sometimes but usually not. And when things went wrong (often!) it would lock up the Deskbar. ifconfig from the Terminal would sometimes lock up so hard ctrl-C wouldn't kill it and neither would ProcessMonitor 'Threads and Usage'.

Could you try to apply the following change and tell if it changes anything for you regarding these lock ups?

diff --git a/src/libs/compat/freebsd_network/device.c b/src/libs/compat/freebsd_network/device.c
index ec2cf94..2b840cc 100644
--- a/src/libs/compat/freebsd_network/device.c
+++ b/src/libs/compat/freebsd_network/device.c
@@ -60,6 +60,7 @@ compat_open(const char *name, uint32 flags, void **cookie)
 	}
 
 	ifp->if_flags |= IFF_UP;
+	ifp->flags &= ~DEVICE_CLOSED;
 	ifp->if_ioctl(ifp, SIOCSIFFLAGS, NULL);
 
 	*cookie = ifp;

[Pete]

Replying to diver:

Could you try to apply the following change and tell if it changes anything for you regarding these lock ups?

Just to clarify, where should I jam from? I applied the patch in src/libs/compat/freebsd_network and did a jam from there, but I only get an '.a' file. Not sure where that is supposed to end up.

[diver]

FreeBSD compat lib is compiled in every driver so you need to jam iprowifi4965.

[Pete]

Replying to diver:

Could you try to apply the following change and tell if it changes anything for you regarding these lock ups?

+	ifp->flags &= ~DEVICE_CLOSED;

Oh what a difference a bit can make... (:-))

Yes, with that patch things are much smoother. I can connect to my network, then connect to my neigbour's, then back to mine, which I could never do before. I did once get the symptom of apparently being connected but a ping to my gateway not working, but I couldn't repeat it.

I noticed also that an ifconfig immediately after boot showed "up broadcast", rather than "up broadcast configuring" for a while, which seems better. I didn't have to wait to connect.

Both an ifconfig command and the NetworkStatus applet seemed to be equally good. No lockups yet.

[Pete]

And even better, when I go into the yard it no longer insists on connecting to Thunderpussy as I reported above!

Vast improvement. Thanks!

[phoudoin]

I guess it's time to make a "Thunderpussy" commit, then ;-)

[phoudoin]

One could wonder about that unused DEVICE_OPEN flag, though.

[diver]

I should note that the patch is coming from #7040 and it would be nice to add Evgeniy Abdraimov as the author of the patch as it was him who made this research.

git commit --amend --author "New Author Name <email@address.com>"

It also worth checking ticket:7040#comment:7 and see if it still applies.

This ticket is mainly about the crash in wpa_supplicant which I suspect appeared after updating it to 2.0 in hrev45431.

[phoudoin]

Second part of Evgeniy's patch applied in hrev46023. I keep this ticket opened until wpa_supplicant crash root cause is found, though.

[diver]

Can this ticket be closed?

[humdinger]

I can't say... Is #11013 related?
I currently have an issue with my router here and switched to wired LAN for the time being. But I don't think connecting via wpa_supplicant is working smoothly in ever situation yet...

[Pete]

Looks to me as if things aren't really right yet, but I'm not sure it's this bug. Unfortunately I've mostly stuck with a pre-PM Haiku revision (hrev45851), as it's customized to my needs, so the problems I've seen may have gone away by now. However I also have a hrev47380 partition that I'm working on.

I just did a quick play in my new partition, and I do see problems, but I guess this ticket was about a crash, and the glitches I hit seem more related to #11013, so I'll try to report them over there when I have a little more experience with them.

[humdinger]

For the some time, my wifi simply worked, i.e. it connected automatically to my wpa2 encrypted network. I usually do "pkgman update", but at one time I did an install of an image over my Haiku installation, i.e. I kept my settings. After that, Haiku refuses to connect when choosing my network from the Deskbar replicant and only works when using ifconfig.

I attach the two syslog outputs. Maybe that can help. The non-working from-Deskbar connect pops up the WPA password window 3 times. The working ifconfig connect only pos it up once, but works after taking its sweet time for about 30 secs.

[humdinger]

not OK, from NetworkStatus replicant in Deskbar

[humdinger]

OK with ifconfig

[humdinger]

I'll attach a current version (hrev51727) of the syslog when trying to connect. The issue seems unchanged, though I'm not confident to judge the syslog's details. Connection if ifconfig has been fast for some time now (I think tqh or korli fixed that a while back).

• attachment:not_OK_from_Deskbar_new.txt​ : with NetworkStatus from Deskbar, every 10 seconds or so the wpa_supplicant window pops up 1, 2, 3, or 4 times directly one after the other. Network name and password is set. Authentication is on "WPA2".

• attachment:OK_with_ifconfig_new.txt​ : with a ifconfig /dev/net/iprowifi4965/0 -ht before joining, wpa_supplicant window comes up once with. Network name and password is set. Authentication is on "Open", I choose "WPA2". It connects. The keystore window doesn't pop up, because I'm already authorized, I guess.

[humdinger]

not ok, hrev51727

[humdinger]

ok, hrev51727

[waddlesplash]

humdinger says wpa_supplicant doesn't crash anymore, and remaining flakiness is another issue.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone