nm unable to connect after editing wireless network profile

[QPrime]

Binary package hint: network-manager

Using Hardy Alpha 6 on an IBM TP R51 with intel 2200 mini-pci wireless adapter and network-manager.gnome v0.6.6-0ubuntu1. All updates applied as of 7th Mar 2008 @ 1:19 (EDT)

Initially allowing automatic creation of the profile by nm to a linksys wap55ag (current linksys firmware) results in a blank "Type" field in the properties dialog for the stored wlan profile (as viewed via the nm wireless network editor). Changing this field from its initial blank value to "Automatic" or "AES-CCMP" and attempting an ap re-associated appears to result in an inactive TP intel 2200 radio interface (no hardware wlan led activity and no ap association). Deleting the wlan profile and allowing nm to re-detect the wlan appears to correct the problem, however any additional editing of the profile "Type" field results in the same issue, requiring deletion of the profile and auto-detection.

[Alexander Sack (asac)]

you are talking about the applet, not about the server, right? (reassigning for now).

[QPrime (mwells)]

Correct, and thanks for the bump.

Everything thus-far seems to be related to the applet and due to the fact that wlan connections work correctly when the applet is left alone, I'd suspect that the issue may indeed be restricted to the applet. Will provide any config. info needed, and thanks for the excellent work.

[QPrime (mwells)]

Window capture to illustrate issue...

[crash (crash369)]

I second this error. Setting 'AES-CCMP' on initial connect results in a blank Type in the wireless networks configuration utility.

Also (I don't know if this is a bug and/or related), but checking "show password" in the wireless networks configuration utility shows a long (hex?) string instead of the plaintext password.

I'm running Hardy 64-bit Desktop release.

[crash (crash369)]

Also second the fact that changing the Type field manually in Wireless Networks utility (nm-editor) will break connectivity after reboot. nm-applet will be stuck in connecting loop with message "Waiting for Network Key from the wireless network..."

package:
network-manager-gnome
0.6.6-0ubuntu3

[crash (crash369)]

sorry to flood the comments... just trying to add some more (hopefully helpful) info...

I have tried setting `wpa_psk_key_mgt` manually through gconf-editor.

In the attached syslog, the first part is what happens if I set the field to '0' (auto) or '8' (aes-ccmp), then you can see me change it to '2' (wpa-psk, i think) and reconnecting.

wireless 'nic':
0c:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61)
iwl4896 driver

router is a buffalo whr-g54s running tomato firmware w/ wireless security set to 'WPA2 Personal (PSK) + AES'

hope this helps.

[Jayson Rowe (jayson.rowe)]

Since it's been a very long time since any additional info was added to this bug, I'm just checking to see if this is still an issue, and find out what additional work should be done on this bug.

[QPrime (mwells)]

Hi Jayson. With a fully patched Hardy install this bug still exists as described in the initial report - using network-manager 0.6.6-0ubuntu5 and network-manager-gnome 0.6.6-0ubuntu3. Crash's posts seem to point to a possible problem with network-manager-gnome incorrectly reading, setting or manipulating the stored keys in system/networking/wireless/networks/<network name>.

I think the issue is related specifically to network-manager-gnome, but I can't offer any additional info without debugging assistance from the launchpad team. As a point of reference, the combination of network-manager 0.7~~svn20081018t105859-0ubuntu1.8.10.1 and network-manager-gnome v0.7~~svn20081020t000444ubuntu1 as deployed on a fully patched Intrepid system work as expected.

[QPrime (mwells)]

Not sure of the current status of this bug. I can only assume that is remains unfixed in Hardy, but fixed in Intrepid+

[Boniek (boniek12p)]

This bug report is being closed due to your last comment regarding this being fixed with an update. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status . Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

[QPrime (mwells)]

Boniek, as indicated in post #8, this bug was still unresolved as of network-manager 0.6.6-0ubuntu5 and network-manager-gnome 0.6.6-0ubuntu3. Taking a look at the change logs for the various packages in Hardy I don't see any indication that this issue has been addressed and I can only assume that the 'fix' is an upgrade from the Hardy LTS release to Intrepid (or greater). This bug was left open due to the LTS status of Hardy, and the fact that it may not have been addressed. Until this issue is corrected (or resolved by a "Won't fix") I'd suggest that it be left open. Unfortunately (for this bug) I am no longer using Hardy and I am unable to confirm the actual status of this bug. Anyone with first-hand knowledge of its status may wish to update or close this report. If this bug is not updated by the time the next LTS (Lucid) is released I'll simply close it at Lucid release.

[Tony Espy (awe)]

@QPrime

I think leaving this open is counter-productive. We know it was fixed in Intrepid, and at this point, the probability that a fix will be backported as an SRU to Hardy is close to nil.

So, we should either change the Status to FixCommitted ( and make clear that the fix is available in Intrepid / 8.10 onwards ), or mark it as WontFix.

As for waiting for Lucid LTS, alpha 2 is already available, and thus it should be possible to confirm that this is working in Lucid now.

[QPrime (mwells)]

Understood. While nm 0.7 made a number of changes to the underlying infrastructure that makes a backport more difficult, it's a pity that this issue was not addressed for an LTS.

[QPrime (mwells)]

This issue has been resolved in Ubuntu 8.10 "Intrepid" (and later releases), but remains unresolved in Ubuntu 8.04 "Hardy". As of 2009.01.20 no Stable Release Update is planned to address this issue, however Network Manager in Hardy remains functional in-spite of this bug.

[QPrime (mwells)]

This issue has been resolved in Ubuntu 8.10 "Intrepid" (and later releases), but remains unresolved in Ubuntu 8.04 "Hardy". As of 2010.01.20 no Stable Release Update is planned to address this issue, however Network Manager in Hardy remains functional in-spite of this bug.

(Correction to date in last post - living in the past is not usually a good thing...)

[Tony Espy (awe)]

@ QPrime

Thanks for your help on this. We should probably change this to FixReleased, as in general FixCommitted means that the fix has been committed to source control, but not necessarily released.

[QPrime (mwells)]

Tony, no problem, and thanks for your input.