Version: 0.1-0.3.svn20060625 (using KDE KDE 3.5.4) Installed from: RedHat RPMs OS: Linux NOTE1: Original bug report against Fedora Extras can be found under <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=205926> NOTE2: This is not a problem like bug #127449, i.e. I can connect to a hidden ESSID without problems. It's just that knetworkmanager doesn't update NM correctly when a new wireless card gets available. Description of problem: I'm using a PCMCIA WLAN card. If the card is not present when knetworkmanager starts up the first time after a boot it doesn't tell the NetworkManager to look out for networks with non-broadcast ESSID. Version-Release number of selected component (if applicable): knetworkmanager-0.1-0.3.svn20060625.fc5 NetworkManager-0.6.4-1.fc5 NetworkManager-gnome-0.6.4-1.fc5 NetworkManager-glib-0.6.4-1.fc5 dbus-qt-0.61-4.fc5 kmod-madwifi-0.9.2-2.2.6.17_1.2174_FC5 madwifi-0.9.2-1.lvn5 NOTE: I had to patch the /usr/sbin/NetworkManager binary so that it doesn't request the madwifi driver, otherwise NM doesn't work with the latest madwifi driver anymore. See also bug #195411. How reproducible: Always Steps to Reproduce: 1. Setup an association to a network with non-broadcast ESSID (ie. a hidden cell) in knetworkmanager 2. Remove the PCMCIA WLAN card and reboot the machine 3. After KDE session has started knetworkmanager insert the PCMCIA WLAN card again Actual results: Only networks with broadcast ESSID show up in the wireless networks list. Expected results: Also non-broadcast ESSID networks known to knetworkmanager should show up in the list. Additional info: Once you restart knetworkmanager or NetworkManager the non-broadcast ESSID networks show up in the list. If you insert the PCMCIA WLAN card after boot but before you login to KDE it also works OK.
Probably a NetworkManager problem, as indicated by the need to restart NetworkManager. What happens if you use nm-applet?
Sorry, don't use GNOME :-)
I wanted to file a new Bug report while this report got listed in the check for duplicates. The bug is: No GUI way to fall back to Knetworkmanager interface management mode after using manual configuration GUI for the interface. No notification about the cause of lack of management. Now i see this is explained by the #3 comment - since NetworkManager ignores all interfaces listed in /etc/network/interfaces, and that's what the knetworkmanager's manual configuration updates. To fix the issue one needs to remove the corresponding entries trom the file, just as directed in http://ubuntuforums.org/showthread.php?t=528421 , where I found out that I wasn't the only confused user. More specifically, manual configuration is not in the knetworkmanager component but it is a configuration panel from KDE that can be shown by issuing "kcmshell kcm_knetworkconfmodule". Nevertheless IMHO either knetworkmanager should not rely on NetworkManager or the "feature" of ignoring manualy configured interfaces that NM introduced should be marked as a regression bug. Let me know if repairing the interfaces file is not a remedy for this bug so I can submit a new bug report.
I am sorry as my comment #3 is a mistakenly submitted comment for a different issue http://bugs.kde.org/show_bug.cgi?id=133809. Please anybody remove it if you are authorized.
#3 - if you still have problems with current versions, try http://vidner.net/martin/software/cnetworkmanager/ to try to create a connection. See http://userbase.kde.org/NetworkManagement for troubleshooting tips.
I have debian unstable as os with kneworkmanager at revision svn1043853. Network manager does not seem to be able to discover hidden network either with wpa or wep. Instead, if we add that network before of disabling ssid broadcast, the connection is added and I can connect to it. Then if I disable ssid broadcast it is able to reconnect to that connection.
Is this still happening?
Can't tell. KNetworkManager has been non-functional since the beginning of KDE4 on Fedora, so I'm not using it any more.
it still happens for me. I have the version 1:0.9+git20110318.941cde9-1 on debian unstable (linux kernel 2.6.38-1).
*** This bug has been marked as a duplicate of bug 209464 ***