network-manager looses connection after 8 hours

[Wolf Rogner]

in Ubuntu 9.04 beta (Linux hb 2.6.28-11-generic #38-Ubuntu SMP Fri Mar 27 09:00:52 UTC 2009 i686 GNU/Linux) network manager looses wireless connection after approximately 8 hours.

This occurs permanently.

It could be triggered by wireless stations appearing or disappearing.

When looking at the peer list after disconnect, there always 20+ stations in the list.
Disabling and enabling wireless network finds only 5 - 10 SSIDs.

This happened in 8.10 beta as well. It became better in 8.10 stable and now is back.
Worse than before: In 8.10 I got the logon to network dialog. I do not get it in 9.04 (well I got it twice, but its not a pattern).

There is another issue:

The password that gets retrieved from the keyring is STILL wrong.

While you are at it: Please fix the bug that when connecting the first time, the password is fetched correctly, on reconnect you get try to use the hash. This does not work.

[Alexander Sack (asac)]

this is a driver bug most likely. Which chipset/driver are you using? Also, there might be a more bleeding edge driver linux-backports-modules-jaunty package; try to install that one and see if after restarting your system your problem resolves.

[Wolf Rogner (war-rsb)]

Most certainly this is a software bug. The same issue happens on different vendor notebooks.
The nx8220 is just my test machine.

Try the following:

Connect to a wireless network using WPA2 / PSK.
Enter the password: testtest

Now in network manager Edit Connection: select the Auto SSID and edit settings. Select the Wireless security tab.

Show password and you will get: 3bd98d9c569fe00e7354e94efed7a9e4138c567094f8684fbc7664e73ebea812

This is not "testtest"

Now disconnect the link (by resetting the router for example). NM tries to reconnect. It will not succeed. The logon dialog will have a password preselected: 3bd98d9c569fe00e7354e94efed7a9e4138c567094f8684fbc7664e73ebea812

Note here: the password is ""testtest" the generated key is 3bd98d9c569fe00e7354e94efed7a9e4138c567094f8684fbc7664e73ebea812.

The key is used instead of the password and run through the routines (wpa_passphrase) again. This can never work.

So: If the connection breaks, a reconnect is not possible because the wrong password/key is used. I have not figured out whether you read from the seahorse container or some other place. The error occurs only in cases of broken wifi connection (btw. the same error happens with mobile internet cards)

This has nothing to do with chipsets. Please fix the error in the software.

[Wolf Rogner (war-rsb)]

Did some more investigation:

the package in question is nm-applet. I think that the files in question are ws-wpa-psk.c and wireless-security.c.

Why does the author presume that if the keylength is 64 chars, it is the key they are dealing and not the passphrase?

Another question: why does the author use two different types of security descriptor?

[Wolf Rogner (war-rsb)]

Could you please change the status from incomplete to something where I can see you take this seriously.

The connection drops on any of my 3 laptops with 9.04. I also run a machine with 7.04. The network remains connected there.

So: The only difference is NM 0.71.

[Pedro Villavicencio (pedro)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release the Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Pedro Villavicencio (pedro)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to New. Thanks again!.

[Wolf Rogner (war-rsb)]

This is a nice way of dealing with bugs.

First you never fix it, then you wait for another release (which has the same bug again) and then you close it.

Do you really think this is an incentive to do beta testing for you?