let the user set timeout and maximum connection attempts

Hello,

it would've been much more useful if you attached your wicd.log to the bugreport; instead of writing an essay.

The "bad password" message might be misleading, but it means that wpa_supplicant failed. You should have a line like "connect result is failed" in your log to testify that.

David, thanks for your response.

We ran 100 system start-up sequences on a fresh clean and fully updated standard installation of xubuntu 12.10.
— The shortest sequences were with 1 BAD PASSWORD error message, followed by a manual click on the Connect button followed by a successful connection.
— The longest sequences of BAD PASSWORD error messages were in excess of 15, each time followed by a manual click on Connect, but without ever resulting in a successful connection (after 15 we performed a system restart).
— The average was 6.7 BAD PASSWORD messages prior to a connection.
I am attaching a wicd.log file of one short sample sequence (they are all similar, and can become very long and repetitive).

As a control, we ran 100 start-up sequences with "network manager" instead of wicd under an unmodified standard xubuntu 12.04 LTS using a different partition on the same machine and using the same access point. Without fail, each time a connection was already established by the time the desktop was fully up and running.

As a final control, we ran 100 start-up sequences with MS Windows 7 on yet another partition. Again, by the time we had a running desktop, the internet connection was already live without exception.

We are about to install 1200 systems. They are workhorses which have to be stable and functional with no frills. An average 10-minute delay in getting systems ready for work represents 2.1% of a working day. That is 25 staff fully paid for doing nothing but clicking the Connect button. Hopefully you will understand an element of frustration here. It is certainly not personal. I hope we can resolve this.

Leo

Hello,

would you please mind sending a log after enabling debug mode? You can do it via the GUI, or edit /etc/wicd/manager-settings.conf and change debug_mode to 1.

Thanks,
David

I'm finding doing this to help alot...

right at the moment it says "Bringing Interface UP" I type in a console "iwconfig wlan0 key on"

right at the first moment you see that, before it gets to the next thing.

that fixes it for me.

using debian unstable here

that is .. to say.... i think it's missing a needed command with iwconfig.

i bet this answers a few reports

Hi David, sorry for the delay. Until yesterday I had no access to our test laptop with wicd.

I am attaching the wicd.log file as recorded with debug mode enabled. The file is very long, more than 1/4 MB until a first successful internet connection was finally established. (These wicd.log files become extremely large after a while even without debug mode enabled, because they never seem to get flushed; they just seem to grow and grow. I cleaned it out before recording the attached file.)

Accessing the internet after a fresh system start this time required 23 attempts, with 22 failed attempts which each time again erroneously signalled a BAD PASSWORD. In all, it took nearly half an hour to get on the internet. And this was despite pressing the disconnect and reconnect buttons immediately after each BAD PASSWORD error message in order to speed things up. Left to its own devices wicd would have taken many times longer even to connect successfully, if at all.

Let me know if you want me to conduct any further tests. Leo

Jason: I'll make sure I'll add that command, just to be on the safe side.

Leo: it seems to be like a problem in wpa_supplicant really: as you can see, when the connection succeeds you have "WPA_CLI RESULT IS COMPLETED", while you don't have that in all other cases.

I guess wpa_supplicant it's taking more time than usual to finish association.

You could try increasing the time it tries -- it's currently set to 35 seconds. Open wicd/wnettools.py, and look for MAX_TIME, and set it to, say, 60. If that solves the issue (i.e. you find a "WPA_CLI RESULT IS COMPLETED" in the log), then we need to find out why wpa_supplicant takes so long to complete (and maybe it could be a good idea letting the user set that timeout from the GUIs).

Thanks for your collaboration,
David

Hi David, thanks for your response and analysis in #8.

Following your suggestion, for testing purposes, we have set the MAX_TIME parameter in wicd/wnettools.py to 135 seconds (instead of the default 35 seconds, and higher than the 60 seconds you suggested in order to be amply on the safe side).

We understand that the wicd daemon is started by wicd's init script during system start-up – before any user logs in. So, without delving into the rather dark underworld of system start-up scripting, we found no easy direct way to time the interval until wicd completes its WiFi connection. However, from the moment the Xubuntu desktop is fully up and running, it takes anywhere between another 35 to 55 seconds (more often near the lower bound of this interval; about 7% of observations fall outside of this interval; these time interval data are approximate and collected over 250 system start-ups using the same system set-up and AP as before).

Importantly, in all 250 cases, wicd completed its WiFi connection successfully without manual intervention and without resorting to automatic retries, and no "BAD PASSWORD" error messages were generated. That suggests that you have indeed nailed down the problem. My sincere congratulations!

Let me summarize:

— Setting the MAX_TIME parameter in wicd/wnettools.py to, say, 120 seconds by default in the next release of wicd and adding an option to the wicd graphical user interface allowing the user to change this time-out value – without manually having to edit the (rather delicate) file wicd/wnettools.py (owned by root) – would therefore appear gracefully to resolve the issue. (This in itself, of course, does not explain why wpa_supplicant takes so much time to complete.)

— Maybe the "BAD PASSWORD" error message – if and when this message is triggered by exceeding the time-out set for wpa_supplicant – could be replaced by a better diagnostic message giving the user a clue where the actual problem lies and how to resolve it.

— A minor final question which emerged during all the testing: Would it be possible to set a reasonable limit to the maximum size of the wicd.log file, flushing the oldest records when new records are added if this limit is exceeded? Currently, wicd.log seems to grow and grow without any upper bound.

Let me know if we can do more to help. Leo

Super, David. And you're mighty fast! Leo

As just discussed on IRC, wicd should just make the user able to configure the timeout and maximum connection attempts, without diving into the code.

Hi David

As far as I can make out, this change hasn't found its way into the (x)ubuntu repositories yet. Can you give an idea when this is expected?

Thanks, Leo

This would make possible to the user set the timeout for ValidateAuthentication() - in both backends. I've not tested it, my kernel doesn't supports wi-fi. Hope it works.