Wireless Network settings not persistent and not effective

Bug #226487 reported by Terry Coles
4
Affects Status Importance Assigned to Milestone
knetworkmanager (Ubuntu)
Won't Fix
Undecided
Unassigned

Bug Description

I have tried Hardy on two computers which have wireless interfaces which both previously worked fine with earlier versions of Kubuntu. In both cases, the symptoms are identical:

KNetworkManager sees the Access Point and gives a good indication of signal strength. It also sees other Access Points in the area. However, when I enter the WEP key, it times out with a failure message.

If I then try to do the settings the other way round, eg using the Network Settings dialog in the System Settings application, I can enter all the data, (including the WEP key), but wireless is not properly enabled (eg it doesn't provide a route to the internet). In previous versions of Kubuntu, I've always found that after this initial setup a reboot is needed, to get wireless to work. In this case all the fields in the Network Settings dialog are blank again after a restart. If I exit the System Settings application and restart it without a reboot, the settings remain, (but still won't work). I've tried to disable and re-enable the network before rebooting, but this has no effect.

I can get wireless to work using the information at http://www.ubuntugeek.com/how-to-troubleshoot-wireless-network-connection-in-ubuntu.html, providing I shut down KNetworkManager first, but can't work out how to make it persistent across reboots. If I try to do the settings manually with KNetworkManager still running I get major errors logged in kern.log and other log files.

I have also reported this at the KDE bug tracker see http://bugs.kde.org/show_bug.cgi?id=161606, because the site came up when I clicked on Report a Bug in the Help Menu. However, it occurs to me that this may be a Hardy problem, rather than a (K)Ubuntu one.

Revision history for this message
Adrien Cordonnier (adrien-cordonnier) wrote :

I confirm that settings are either not (always) persistent or not (always) effective.

At my uncle's place, I have to configure manually the gateway (because the Wifi router is connected to the DSL router with a LAN port, not with the WAN port. Don't ask me why). If I change the gateway in manual settings in Knetworkmanager, the new gateway is not taken into account:

- I change the gateway IP;
- I apply the changes;
- the new gateway IP is displayed in Knetworkmanager but the old gateway IP is displayed by ifconfig (the later is effective so the connection does not work);
- I close and open knetworkmanager manual config window which then show the old gateway IP.

So I stopped Knetworkmanager and configured the network in command line: "sudo route del default; sudo route add default gw 192.168.0.1" and it works.

I say settings are not **always** persistent because at my aunt's place, knetworkmanager recognized the Wifi AP name and connected right away: it means it had saved the WPA key more than 1 year ago. The security problem is I don't know where this is saved because I don't use Kwallet and I don't have any network profile in Knetworkmanager!

Revision history for this message
Jonathan Thomas (echidnaman) wrote :

Thank you for taking the time to report this bug and helping to make Kubuntu better. The KDE3 version of KNetworkManager has been discontinued by its original authors. This unfortunately means that there will be no more bugfix releases, and updates in general will be limited to those fixing security flaws.

While we cannot fix your bug, the good news is that the applet has been totally rewritten for KDE4 in the upcoming Kubuntu 9.10 release. There is a good chance that this bug is no longer an issue with the new applet. If you find any similar or new issues with the applet included in Kubuntu 9.10, we would politely ask you to file them as new bugs against the "plasma-widget-networkmanagement" package.

Thanks in advance for your cooperation and understanding.

Changed in knetworkmanager (Ubuntu):
status: New → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.