Wifi doesn't connect

[pulkomandy]

On my home network I can't get the Wifi to connect. I have tried both using NetworkStatus and using a script to set the SSID and key.

The wpa_supplicant window sometimes says the network is open (it isn't, it's WPA2). Not a lot of things in the syslog (a few state changes but no error or anything).

How can I debug this?

It used to work on this machine and I think it works with some other access points.

[nephele]

I think the first part would be to get a log from wpa_supplicant or the net_server itself.

For net_server you need to blacklist net_server so launch_rostet will not autostart it. and the manually launch it in a terminal (from a haiku build i suppose? launch_rostet sadly cant be told a service is just disabled yet)

For wpa_supplicant you can quit the application in teamMonitor and then run it in the terminal directly, and then use the network preferences to get it to do something. (you then get the output to stdout)

[pulkomandy]

This is a crazy and unconvenient way to debug things. Can't they just send their logs to syslog or to some logfile of their own? How do you tolerate working this way?

[nephele]

Many unix daemons are designed with "log to stdout" per default, and this is certainly true for daemons we import. Yes we could make them log somewhere else, but at this point I'd like to have a proper log viewer integrated into haiku which displays logs graphically and can filter by generating application etc.

There are quite a bit of "logged to stdout" things we don't catch now, also of stuff started by launch_roster.

It's not there yet anyhow, so i'm left with the other way, yes it is inconvenient, I have not found a better way with the current system design.

[pulkomandy]

It seems not hard at all to have launch daemon redirect stdout/stderr to some logfile or syslog. That just needs closing stdout and opening the logfile as fd 0, right? Do we really not have anything like that in place yet?

[nephele]

I don't think we do, and yes for the "standard" case that would be enough. the logging daemon receiving this would be nicer, it already knows how to roll over log files and such (and would be the place of contact for a log viewer)

[waddlesplash]

This is a crazy and unconvenient way to debug things.

wpa_supplicant logging is very verbose most of the time and would clog up the syslog. For OpenBSD drivers it is much less verbose as the kernel stack handles a lot more, but that's another matter.

The wpa_supplicant window sometimes says the network is open (it isn't, it's WPA2).

This sounds relevant. The wpa_supplicant should be getting the encryption type from the network join request. If it doesn't, that parameter getting lost could prevent joins from succeeding.

Try using ifconfig to join and see if it makes any difference.

[pulkomandy]

No, ifconfig doesn't help. That's what I meant by "using a script" in the ticket description.

[olegkapitonov]

I have the same issue here https://dev.haiku-os.org/ticket/18342

I attached syslog and wpa_supplicant log during auth failure.

[olegkapitonov]

I tried to look what is going on using a WiFi Monitor running on another machine.

When connecting from Linux, I can clearly see how the card sends an authentication request.

When connected from Haiku, the card does not send anything!

And then wpa_supplicant writes in the log that an authentication timeout has occurred.

[waddlesplash]

Your ticket is a very different scenario than this one, because there are two different WPA stacks in use. The driver used with your ticket uses wpa_supplicant's WPA(2) stack, while the driver in this ticket uses the OpenBSD WPA(2) stack. Thus there is a good chance the problems are unrelated.

[pulkomandy]

I have replaced my wifi access point with a newer one (provided by my ISP), and also did a clean install on my Haiku machine, and now things are working fine. No need to spend more time on this I think.