wicd

Bug #1084380
Comment #9

Comment 9 for bug 1084380

Revision history for this message

Leo H (leo-h-hildebrandt) wrote on 2013-01-07: Re: wicd wrongly and repeatedly reports BAD PASSWORD error

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

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

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.)

— 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