let the user set timeout and maximum connection attempts

[Leo H]

System:
-------
– Fresh clean installation of xubuntu 12.10, fully updated using the xubuntu software updater.
– WiFi access point with a strong (over 80%) signal. This access point is fully functional with "network‑manager" on a second identical instance of xubuntu 12.10 on a different partition on the same netbook.
– Removed using synaptic (including configuration files): network‑manager, …‑gnome, …‑pptp, …‑pptp‑gnome.
– Installed using synaptic and the ubuntu quantal (12.10) repos: wicd‑daemon, wicd‑gtk, python‑wicd.
– Configured the WiFi network in wicd with correct SSID and WPA2 password data.
– In xubuntu Settings > Start‑Up Applications: removed tick before Network Manager, added tick before wicd.
– System powered off and restarted.

Bug:
----
– wicd fails to connect on system start‑up.
– Open the wicd "Choose from the networks below" panel and click the "Connect" button.
– After an attempt to connect, wicd reports "BAD PASSWORD".
– This is both incorrect and confusing, because the password is correct.
– Click the "Connect" button again.
– After an attempt to connect, wicd again reports "BAD PASSWORD".
– After four or more such instructions to connect followed by a "BAD PASSWORD" error message, wicd finally makes a successful connection. This ultimately successful connection event occurs without having made any changes to the wicd settings for the access point after system power-up. This proves the "BAD PASSWORD" error message itself to be false.

Analysis:
---------
Either
  (1) This is a bug in wicd.
Or
  (2) This is a bug in the implementation / operation of wicd in xubuntu.

For the user, it is irrelevant whether it is bug (1) or bug (2). It simply needs to be resolved, either by the wicd developers or by the wicd developers in cooperation with the xubuntu developers.

Clearly, however, at least in part the fault lies with wicd itself: It repeatedly misdiagnoses the fault and it repeatedly puts out a plainly wrong and misleading error message.

Comment:
--------

Shifting the buck to solve this bug either to other developers or to the computer user does not resolve anything. Nor do supposed workarounds. The latter, of course, include the complete removal of "network‑manager". Switching "network‑manager" off by unticking it in xubuntu Settings > Start-Up Applications should suffice.

In addition, the plethora of alleged remedies for this bug touted on internet fora and in web blogs by quacks, cli junkies and well-intended amateurs are a time-consuming and an all too often misguided distraction. Instead, clear and authoritative user documentation and trouble-shooting instructions are a sine qua non for any decent piece of application software.

This is, of course, a well-known recurring bug which has been reported widely, and it has a history going back many years. But, while critical, it remains unresolved.

In these days, the internet is an elementary, fundamental and routine resource in IT usage.

It is quite appalling that something as elementary as simply making an internet connection still requires active user intervention and continues to produce user confusion and frustration.

[David Paleino (dpaleino)]

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.

[Leo H (leo-h-hildebrandt)]

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

[David Paleino (dpaleino)]

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

[jason mclaughlin (mcjason)]

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

[jason mclaughlin (mcjason)]

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

i bet this answers a few reports

[Leo H (leo-h-hildebrandt)]

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

[David Paleino (dpaleino)]

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

[Leo H (leo-h-hildebrandt)]

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

[Leo H (leo-h-hildebrandt)]

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

[David Paleino (dpaleino)]

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.

[Leo H (leo-h-hildebrandt)]

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

[Ramon (ekisu)]

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.