Re: Need more info re: FC6 NetworkManager woes
On Thu, 2006-12-07 at 19:46 -0500, Tony Falcone wrote: Hi one again, In former postings I have recounted my troubles getting NetworkManager to work on my FC6 box. As I noted previously, according to the logs, I never get to stage 3 of 5, IP configuration. I started trying to diagnose the problem further, using the nm-supplicant-test tool. Accordingly, after stopping NetworkManager (and NetworkManagerDispatcher), I ran # nm-supplicant-test eth1 /etc/wpa_supplicant/wpa_supplicant.conf and received the following output: ap_scan: 0 Key: ssid, Value: ANY Key: key_mgmt, Value: NONE SUP: sending command 'INTERFACE_ADD eth1wext /var/run/wpa_supplicant ' ioctl[SIOCSIWAUTH]: Operation not supported WEXT auth param 7 value 0x1 - SUP: response was 'OK' SUP: sending command 'AP_SCAN 0' SUP: response was 'OK' SUP: sending command 'ADD_NETWORK' SUP: response was '0' SUP: sending command 'SET_NETWORK 0 ssid ANY' SUP: response was 'OK' SUP: sending command 'SET_NETWORK 0 key_mgmt NONE' SUP: response was 'OK' SUP: sending command 'ENABLE_NETWORK 0' SUP: response was 'OK' Activation (eth1/wireless): association took too long (20s), failing activation. sendmsg(CTRL_IFACE monitor): No such file or directory Is your wireless network _really_ called ANY ? Dan (As an aside, I tried setting ap_scan=1 in the configuration file, but this didn't seem to change anything.) If there is anything here that can help someone tell me what is going wrong, I would really appreciate it; this is driving me crazy. (Again, I am running FC6, kernel 2.6.18-1.2849.fc6, with the hostap / hostap_pci driver and a Prism 2.5 card.) Thanks, Tony ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM do not see any network
On Thu, 2006-12-07 at 21:57 -0500, Darren Albers wrote: On 12/6/06, Darren Albers [EMAIL PROTECTED] wrote: I'll check out launchpad tonight and see what bugs are filed and also look at what patches have been applied to the package and see if I can correlate any of them to the recent problems people have reported. Looking over launchpad last night I see basically the same bugs repeated over and over regarding specific wireless cards but I did not see this specific issue. I also looked at the patches and there are 9 patches applied to the base 0.6.3 tarball. I am not sure why Ubuntu is not at 0.6.4 but I think the maintainer may not have had the time between Dapper and Edgy. The patches seem relatively minor (Though I am probably not a good judge of that ;-) ) I can post all the patches if someone would like me to. Here they are in summary: Supplicant timeout patch: Increases the timeout when trying to associate to 60 seconds. Somewhat bogus, increasing timeouts is the wrong thing to do... dbus_access_network: adds the user haldaemon to Networkmanager.conf Debian specific, since debian uses groups to determine capabilities. In Fedora and SUSE this functionality is provided by pam_console and the at_console=True tag in the NM dbus conf file. if_fix: adds #define _LINUX_IF_H resolvconf patch: changes the function nm_system_should_modify_resolve_conf to return false in src/backends/NetworkManagerDebian.c dispatch_more_events: Seems to add pre-up and post-down events to dispatcher.d Wasn't this always an option? Maybe what someone asked earlier about running a command before an interface is activated is possible with dispatcher.d with this patch? Interesting; these events are quite a bit less interesting than it may seem. 'pre-up' would be time-bounded, since NM certainly doesn't call out to synchronous, blocking scripts when it brings up a connection, nor should it. So whatever script gets called here for pre-up will have to be pretty fast, because NM isn't going to wait for it before continuing. This is quite racy and therefore wrong. I'm not sure what post-down means; there's already the disconnected event from the dispatcher which executes scripts when the connection is terminated. disabled_devices: This tells NM not to touch devices managed in /etc/network/interfaces Right; everybody does this and that's fine; but Ubuntu seems to do it automatically without telling users what's going on. SUSE has a config option in YAST, and half the questions we get here are about this problem in Ubuntu, because people don't realize that touching something in a config tool there turns something else off in NM. rml_wpa_workarounds: Robert's famous wpa workarounds patch ;-) hostap-supplicant-driver: adds a workaround for the hostap driver What does this one do? dbus 0.9: Changes dbus_connection_disconnect to dbus_connection_close ? Yes, this is legit and should be in CVS. I think it may have already been committed to HEAD. I saw in the release notes for Feisty beta (I forgot the catchy code Feisty Fawn Herd 1 :) name they used) that NM might be the default network management utility for Feisty so I think the testing period there will hopefully shake out any issues with their packages and maybe (hopefully?) will get some patches sent upstream. Hmm, I thought Ubuntu was still punting NM-by-default since it doesn't cover a bunch of use-cases like static IP. That's fine, Fedora doesn't turn it on by default either for that same reason. SUSE's out in front a bit here, which actually helps everyone out by exposing issues and problems. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM do not see any network
On 12/8/06, Dan Williams [EMAIL PROTECTED] wrote: On Thu, 2006-12-07 at 21:57 -0500, Darren Albers wrote: dispatch_more_events: Seems to add pre-up and post-down events to dispatcher.d Wasn't this always an option? Maybe what someone asked earlier about running a command before an interface is activated is possible with dispatcher.d with this patch? Interesting; these events are quite a bit less interesting than it may seem. 'pre-up' would be time-bounded, since NM certainly doesn't call out to synchronous, blocking scripts when it brings up a connection, nor should it. So whatever script gets called here for pre-up will have to be pretty fast, because NM isn't going to wait for it before continuing. This is quite racy and therefore wrong. I'm not sure what post-down means; there's already the disconnected event from the dispatcher which executes scripts when the connection is terminated. I see what this does (whether this is smart or not is beyond me...), the package adds a script to dispatcher that users these two new events to call the general networking configuration items that are required by Ubuntu. For example pre-up is used to trigger a script that calls the standard networking scripts for Debian/Ubuntu: The first sets some wireless options using the wireless tools and the second starts wpa_supplicant. The postdown does the opposite and shutsdown wpa_supplicant and then sets all the wireless configuration options to their defaults again. I think this is done so that people can set some specific items in /etc/network/interfaces such as speed, channel etc.. but as long as they keep the interface set to use DHCP Network Manager will continue to manage it. Could this be a potential problem for Network Manager if things like the rate are set there? disabled_devices: This tells NM not to touch devices managed in /etc/network/interfaces Right; everybody does this and that's fine; but Ubuntu seems to do it automatically without telling users what's going on. SUSE has a config option in YAST, and half the questions we get here are about this problem in Ubuntu, because people don't realize that touching something in a config tool there turns something else off in NM. I agree and I wonder if until the recent announcement that they really wanted people to use NetworkManager? Their point was probably that rewriting the gnome-network-panel to inform the users of this was too much work to make it by release or that there was nobody who wanted to take it on. hostap-supplicant-driver: adds a workaround for the hostap driver What does this one do? If it detects any of the following kernel_drivers hostap_pci, hostap_cs, and hostap_plx it passes hostap to wpa_supplicant. I saw in the release notes for Feisty beta (I forgot the catchy code Feisty Fawn Herd 1 :) name they used) that NM might be the default network management utility for Feisty so I think the testing period there will hopefully shake out any issues with their packages and maybe (hopefully?) will get some patches sent upstream. Hmm, I thought Ubuntu was still punting NM-by-default since it doesn't cover a bunch of use-cases like static IP. That's fine, Fedora doesn't turn it on by default either for that same reason. SUSE's out in front a bit here, which actually helps everyone out by exposing issues and problems. Here is the spec they plan on implementing: https://blueprints.launchpad.net/distros/ubuntu/+spec/network-roaming It seems very redundant to 0.7 which I thought would be out with plenty of time for Feisty April release date... Is 0.7 still on track for Jan? On a side note I used Fedora for the first time on a Mac Mini my wife gave me for my birthday (I really tried to like MAC OS but little things kept annoying me about it) and I was impressed. It shows a lot of polish and there were some things that I really liked about it and it will probably stay since my needs on that system are a lot less than on my laptop so I won't need to learn all the nuances of another distro. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM do not see any network
On Fri, 2006-12-08 at 12:30 -0500, Darren Albers wrote: On 12/8/06, Dan Williams [EMAIL PROTECTED] wrote: On Thu, 2006-12-07 at 21:57 -0500, Darren Albers wrote: dispatch_more_events: Seems to add pre-up and post-down events to dispatcher.d Wasn't this always an option? Maybe what someone asked earlier about running a command before an interface is activated is possible with dispatcher.d with this patch? Interesting; these events are quite a bit less interesting than it may seem. 'pre-up' would be time-bounded, since NM certainly doesn't call out to synchronous, blocking scripts when it brings up a connection, nor should it. So whatever script gets called here for pre-up will have to be pretty fast, because NM isn't going to wait for it before continuing. This is quite racy and therefore wrong. I'm not sure what post-down means; there's already the disconnected event from the dispatcher which executes scripts when the connection is terminated. I see what this does (whether this is smart or not is beyond me...), the package adds a script to dispatcher that users these two new events to call the general networking configuration items that are required by Ubuntu. For example pre-up is used to trigger a script that calls the standard networking scripts for Debian/Ubuntu: The first sets some wireless options using the wireless tools and the second starts wpa_supplicant. The postdown does the opposite and shutsdown wpa_supplicant and then sets all the wireless configuration options to their defaults again. I think this is done so that people can set some specific items in /etc/network/interfaces such as speed, channel etc.. but as long as they keep the interface set to use DHCP Network Manager will continue to manage it. Could this be a potential problem for Network Manager if things like the rate are set there? disabled_devices: This tells NM not to touch devices managed in /etc/network/interfaces Right; everybody does this and that's fine; but Ubuntu seems to do it automatically without telling users what's going on. SUSE has a config option in YAST, and half the questions we get here are about this problem in Ubuntu, because people don't realize that touching something in a config tool there turns something else off in NM. I agree and I wonder if until the recent announcement that they really wanted people to use NetworkManager? Their point was probably that rewriting the gnome-network-panel to inform the users of this was too much work to make it by release or that there was nobody who wanted to take it on. hostap-supplicant-driver: adds a workaround for the hostap driver What does this one do? If it detects any of the following kernel_drivers hostap_pci, hostap_cs, and hostap_plx it passes hostap to wpa_supplicant. I saw in the release notes for Feisty beta (I forgot the catchy code Feisty Fawn Herd 1 :) name they used) that NM might be the default network management utility for Feisty so I think the testing period there will hopefully shake out any issues with their packages and maybe (hopefully?) will get some patches sent upstream. Hmm, I thought Ubuntu was still punting NM-by-default since it doesn't cover a bunch of use-cases like static IP. That's fine, Fedora doesn't turn it on by default either for that same reason. SUSE's out in front a bit here, which actually helps everyone out by exposing issues and problems. Here is the spec they plan on implementing: https://blueprints.launchpad.net/distros/ubuntu/+spec/network-roaming It seems very redundant to 0.7 which I thought would be out with Right; much of that is pretty redundant for 0.7. But a few other bits seem right on. plenty of time for Feisty April release date... Is 0.7 still on track for Jan? Maybe February or early March, but certainly before April. The wpa_supplicant control parts are within sight of being done, and then it's on to speccing out the new configuration interface and doing multiple active devices, which will actually _simplify_ the code and DBus interface, for a change. On a side note I used Fedora for the first time on a Mac Mini my wife gave me for my birthday (I really tried to like MAC OS but little things kept annoying me about it) and I was impressed. It shows a lot of polish and there were some things that I really liked about it and it will probably stay since my needs on that system are a lot less than on my laptop so I won't need to learn all the nuances of another distro. Neat. 0.7 will get into FC7 at least, and there it will certainly be better integrated. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Thank you - NM works well with D-Link WNA-2330 adapter and WPA2 OpenWRT router
Hello, I just want to say thank-you to the developers and other people involved in making NM what it is today. I was struggling to improve and secure my home network while still allowing my brother to connect his Ubuntu 6.10 laptop to the network without wires. The easy part of the equation was purchasing a OpenWRT supported router. The hard part was replacing the laptop's old PCMCIA Linksys WPC11 v3 802.11b adapter with something that can do WPA rather than WEP. I tried a few different PCMCIA adapters, but what I could get either didn't support any encryption other than the flawed WEP or it just didn't have stable Linux drivers. The last card which I tried was D-Link WNA-2330 [1]. I purchased it from a big box store Futureshop [2] (so I could always return it if it didn't work) and it supports WPA2. It worked out of the box on Ubuntu with the madwifi drivers. It successfully established a WPA2 encrypted connection to a test router with proprietary Linksys firmware. However, I was only able to establish a WEP encrypted link to my WRT router. For some reason, in WPA mode the client adapter de-associated from the router seconds after being connected. I was ready to give up trying to debug the issue and even started considering setting up some kind of an encrypted tunnel on top of a WEP connection when someone suggested that I give NetworkManager a try. To my surprise the installation and configuration went smoother than I expected. I didn't have to compile anything, nor tweak any config files (not that I mind). I didn't even have to configure NM to run automatically at the next boot. All I had to do was click to select my network out of the discovered list, select the encryption type and type in the passkey (and type in a keyring password). Everything worked so well, that the (relatively) worst annoyance was the keyring access prompt at each logon. After a couple of days of smooth operation my brother was very happy with the wireless connection because it was faster than his old 802.11b adapter, and I was happy now that my home network was secured by WPA2 encryption rather than WEP. Finally, I was even able to get rid of the keyring annoyance too [3]. Thanks a lot for making a great solution for non-technical users using Linux on laptops! [1] - http://www.dlink.com/products/?pid=472sec=0 [2] - http://www.futureshop.ca/catalog/proddetail.asp?logon=langid=ENsku_id=0665000FS10080887catid=19997 [3] - http://ubuntuforums.org/showthread.php?t=192281 P.S. I'm not subscribed to this mailing list. -- () ASCII Ribbon Campaign /\ - against HTML mail vCards ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
network-manager-openvpn remote port?
Is there a way to specify a non-standard remote port to use with network-manager-openvpn? I don't see anything on the vpn config gui, nor could I find anything conclusive via Google. Tia, -Jim P. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
