Re: more than one default gw route
My situation is less complicated. I have a laptop and a desktop. the laptop is connected only to wireless, but the desktop is connected also to wired and wireless. I have 2 routers placed in different rooms: I can't reach the wireless router with network cables, and I can't move the wireless router near the cables if I want all my rooms to be served by the wireless signal. When the laptop is off, and I use the desktop, the wired router is on, and the wireless router is off (I don't want to use wireless if I can use wired). But when I need also my laptop, I switch on also the wireless routed, and the wired router loses the ADSL connection (which of course is taken by the wireless router). When this happens, the default gatway of my desktop pc is still set up to the wired router, even if it connects also to the wireless router. So the only thing I can do to get connected is either to unplug the cable or to switch off the wired router. This shouldn't be necessary ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: periodic_update(): Roamed ...
On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote: Dan Williams wrote: On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. How would I check this? Should it be obvious from iwlist scan ? That returns the current AP along with the other visible ones. Also, reviewing the comments in bug 291760, this problem is not just isolated to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, ipw2100, rtl8187, and b43, across multiple kernel and driver revisions. As such it seems unlikely to be the drivers' fault. Depends; it might show up in that scan, or it might not. If you can reliably get it to show up every time, that's great. But until 2.6.30, mac80211-based drivers would not always return the current AP. And some of the older drivers don't either, though fullmac drivers are more likely to be OK there. There is one window where NM wouldn't be able to find the AP; if NM just did a scan, and then the card reassociates to a different AP that's not in the scan list, and doesn't send an GIWSCAN event so that the AP list gets pulled (ipw2x00 do this, other drivers might not), then when NM goes to pull the BSSID off the card, the scan list doesn't contain the current AP. What NM should be doing here is to request that the supplicant grab the scan list again when it sees a BSSID it doesn't know about, but that's somewhat complicated. If the driver doesn't return the frequency of the BSSID in the scan results, or that frequency doesn't match what the card reports from SIOCGIWFREQ, then NM also can come up with (none). Check that the information from an 'iwlist scan' for that BSSID matches what 'iwconfig' reports when associated to that specific AP. So in conclusion there are actual driver bugs; (a) not all drivers scan results contain the currently associated AP in every scan, and (b) not all drivers emit scan results events when they associate to a new AP that's not already in the scan list, and finally (c) some drivers are just busted and return wrong channel information. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Newbie question on occasional NM problem
On Sat, 2009-04-25 at 13:41 +0100, Timothy Murphy wrote: I'm running Fedora-10/KDE on a few laptops, and have just joined the NM mailing list, having moaned about (and sometimes praised) NM on the Fedora mailing list for several years. I'm currently using a Thinkpad T43 with a PCMCIA classic Orinoco gold WiFi card. I guess NM connects fine about 85% of the time when I boot up. The other 15% of the time it doesn't connect, and I have to re-boot. It then connects about 75% of the time; in the remaining cases it connects on the third try. Looks like the orinoco card isn't returning your AP in the scan results perhaps? Can you run 'nm-tool' when you notice NM not connecting to your AP automatically, and report what it says for the wireless networks that 'eth1' can see? Do you see your AP if you run 'iwlist eth1 scan' (as root)? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network manager Question
GSM or CDMA again? If GSM, you'll need to ensure you set the APN. You can also try to put in a fake username and password, some modems require that. It shouldn't actually matter what they are, because the password is only between you and the modem, and isn't relayed to the network at all. To further debug, you could stop NetworkManager (using the Ubuntu service control applet, whatever that is), then open a terminal, and type: su -(then enter your user password) NM_PPP_DEBUG=1 NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon and then plug in your modem, and try to connect. When it fails, copy the output from that terminal window into a reply to this mail. Dan On Fri, 2009-04-24 at 20:32 -0700, Craig wrote: After it plug it will pick up the pc card but will not connect to the internet. --- On Fri, 4/24/09, Dan Williams d...@redhat.com wrote: From: Dan Williams d...@redhat.com Subject: Re: network manager Question To: Craig fasteliteprogram...@yahoo.com Cc: networkmanager-list@gnome.org Date: Friday, April 24, 2009, 11:50 AM On Fri, 2009-04-24 at 08:12 -0700, Craig wrote: I got a Sierra wireless aircard 881 pc card.I got ubuntu 9.04 and it pick up my pc card but when it try to connect there no light on the pcard when i try t connect to it.I think it the network manger i had no prob in the ubuntu 8.10 i had to update it but there no update for this one. i hope someone can help me.:) After the card is plugged in, does it show in the NetworkManager menu? If not, can you provide the output of 'lsusb' for me? Does it put an icon on the desktop when you plug it in? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: more than one default gw route
On Tue, 2009-04-28 at 09:40 +0200, Nicolò Chieffo wrote: My situation is less complicated. I have a laptop and a desktop. the laptop is connected only to wireless, but the desktop is connected also to wired and wireless. I have 2 routers placed in different rooms: I can't reach the wireless router with network cables, and I can't move the wireless router near the cables if I want all my rooms to be served by the wireless signal. When the laptop is off, and I use the desktop, the wired router is on, and the wireless router is off (I don't want to use wireless if I can use wired). But when I need also my laptop, I switch on also the wireless routed, and the wired router loses the ADSL connection (which of course is taken by the wireless router). When this happens, the default gatway of my desktop pc is still set up to the wired router, even if it connects also to the wireless router. So the only thing I can do to get connected is either to unplug the cable or to switch off the wired router. To be honest, you'd have to do manual twiddling no matter what. Even if NM supported per-interface 'disable' sort of thing, you'd need to do that manually. Since the cable is plugged in, and the wired router does DHCP, and the wired connection still has a DHCP address, that's a valid route. It's just not a route to the internet anymore. But that's quite hard to determine in a way that's not horrible to some provider; you can't really just pick a site to ping by default (see [1]). Even if there was a mechanism to determine whether a specific route could reach the internet or not, it would have to be quite good to be used by default to move the default route around, otherwise it could break perfectly good existing connections. So if NM let you disable the wired interface, you'd have a few choices: 1) turn off the wired router 2) unplug the wired cable 3) manually disable the wired interface through some UI or something I'm not opposed to adding some sort of MAC-detection or ping functionality to NM to enhance the decision of what route actually gets to the internet, but it shouldn't turned on by default due to security issues (MAC spoofing) and DoS (ping). Dan [1] http://www.techworld.com/security/news/index.cfm?NewsID=409 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: how can I disconnect?
On Mon, 2009-04-27 at 19:09 +0200, Michael Biebl wrote: Nicolò Chieffo wrote: So I propose this: when you click on a network to which you are currently connected (wired or wireless), you get disconnected. Now the default behavior is instead of renewing the connection and the IP address. What do you think of this proposal? I think this is pretty counter-intuitive behaviour. If such a feature is to be added to nm-applet it should imho be implemented as a separate clickable (disconnect) icon next to the connection. Afaicr, the mockups that were floating around regarding the new gui for nm-applet had something liks this. Yes, were this to be implemented, it would be a separate toggle. There are a few levels of disconnected here though: 1) NM completely off (ie, sleep) 2) specific device disconnected, disabled, and in power-save mode (ie, PHY down or rfkilled) 3) specific device disconnected, though still powered on and scanning, but doesn't automatically activate any connections The issue is conveying to the user the specific meaning of (2) and (3). Perhaps (2) == Disabled while (3) == Manual or something like that. Another question comes to mind; if a user switched to Manual mode, would that disconnect the current connection (if any), or leave it active? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: umts connection closed after succefull ppp negotiation
On Mon, 2009-04-27 at 14:14 +0200, Alessandro Bono wrote: Hi I'm testing my new umts connection but seems there are problem with NM on my system I tried with two different modem (onda et505up and onda mt503hsa) with the same result warning pppd_timed_out(): Looks like pppd didn't initialize our dbus module not seems influence the result, it's possible to remove this warning changing a dbus acl but without any difference below full log of a connection with pppd debug enabled and some info of my system any idea how to debug or workaround this problem? Stop NM, then as root: NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon and lets see what PPP thinks. You probably also want to try setting a username and password explicitly, which some devices seem to really want. Dan thanks ps please cc to me, I'm not subscribed to ml distribution ubuntu jaunty 64bit dpkg -l | grep network-manager ii network-manager 0.7.1~rc4.1.cf199a964-0ubuntu2 network management framework daemon ii network-manager-gnome 0.7.1~rc4.1-0ubuntu2 network management framework (GNOME frontend ii network-manager-openvpn0.7.1~rc4.1.20090323 +bzr27-0ubuntu2network management framework (OpenVPN plugin ii network-manager-pptp 0.7.1~rc4.20090316 +bzr23-0ubuntu3 network management framework (PPTP plugin) ii network-manager-vpnc 0.7.1~rc4.20090316 +bzr21-0ubuntu2 network management framework (VPNC plugin) dpkg -l | grep ppp ii ppp 2.4.5~git20081126t100229-0ubuntu2 Point-to-Point Protocol (PPP) - daemon Apr 27 14:05:08 champagne NetworkManager: info Activation (ttyUSB2) starting connection 'TIM' Apr 27 14:05:08 champagne NetworkManager: info (ttyUSB2): device state change: 3 - 4 Apr 27 14:05:08 champagne NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) scheduled... Apr 27 14:05:08 champagne NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) started... Apr 27 14:05:08 champagne NetworkManager: debug [1240833908.133093] nm_serial_device_open(): (ttyUSB2) opening device... Apr 27 14:05:08 champagne NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) complete. Apr 27 14:05:08 champagne NetworkManager: info (ttyUSB2): powering up... Apr 27 14:05:08 champagne NetworkManager: info Registered on Home network Apr 27 14:05:08 champagne NetworkManager: info Associated with network: +COPS: 0,0,Telecom Italia Mobile,0 Apr 27 14:05:08 champagne NetworkManager: info Connected, Woo! Apr 27 14:05:08 champagne NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) scheduled... Apr 27 14:05:08 champagne NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) starting... Apr 27 14:05:08 champagne NetworkManager: info (ttyUSB2): device state change: 4 - 5 Apr 27 14:05:08 champagne NetworkManager: info Starting pppd connection Apr 27 14:05:08 champagne NetworkManager: debug [1240833908.566302] nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock nodefaultroute ttyUSB2 noipdefault noauth usepeerdns lcp-echo-failure 0 lcp-echo-interval 0 ipparam /org/freedesktop/NetworkManager/PPP/0 plugin
Re: network manager Question
NetworkManager: info starting... NetworkManager: WARN nm_dbus_manager_start_service(): Could not acquire the NetworkManager service as it is already taken. NetworkManager: WARN main(): Failed to start the dbus service. NetworkManager: info exiting (error) --- On Tue, 4/28/09, Dan Williams d...@redhat.com wrote: From: Dan Williams d...@redhat.com Subject: Re: network manager Question To: Craig fasteliteprogram...@yahoo.com Cc: networkmanager-list@gnome.org Date: Tuesday, April 28, 2009, 10:17 AM GSM or CDMA again? If GSM, you'll need to ensure you set the APN. You can also try to put in a fake username and password, some modems require that. It shouldn't actually matter what they are, because the password is only between you and the modem, and isn't relayed to the network at all. To further debug, you could stop NetworkManager (using the Ubuntu service control applet, whatever that is), then open a terminal, and type: su - (then enter your user password) NM_PPP_DEBUG=1 NM_SERIAL_DEBUG=1 /usr/sbin/NetworkManager --no-daemon and then plug in your modem, and try to connect. When it fails, copy the output from that terminal window into a reply to this mail. Dan On Fri, 2009-04-24 at 20:32 -0700, Craig wrote: After it plug it will pick up the pc card but will not connect to the internet. --- On Fri, 4/24/09, Dan Williams d...@redhat.com wrote: From: Dan Williams d...@redhat.com Subject: Re: network manager Question To: Craig fasteliteprogram...@yahoo.com Cc: networkmanager-list@gnome.org Date: Friday, April 24, 2009, 11:50 AM On Fri, 2009-04-24 at 08:12 -0700, Craig wrote: I got a Sierra wireless aircard 881 pc card.I got ubuntu 9.04 and it pick up my pc card but when it try to connect there no light on the pcard when i try t connect to it.I think it the network manger i had no prob in the ubuntu 8.10 i had to update it but there no update for this one. i hope someone can help me.:) After the card is plugged in, does it show in the NetworkManager menu? If not, can you provide the output of 'lsusb' for me? Does it put an icon on the desktop when you plug it in? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Diskless clients and NetworkManager
On Sun, 2009-04-26 at 23:36 +0200, David Sundqvist wrote: Hi, I'm looking for some suggestions as to how to configure Network Manager appropriately and safely for clients booting off PXE with iSCSI root. The clients are Fedora 10 with NM 0.7.0.99. Currently the network connection is unmanaged by NM, but as desktop programs start using NM, it would be nice if it would be possible to configure a connection that NM will see, but never, ever, attempt to touch in any way (any kind of hiccup in the device will result in instant freeze as swap goes off line which tends to put a permanent stop to any further attempts to do anything at all). The boot is basically done off PXE, a fixed IP address (tied to MAC) is assigned via DHCP, and then it loads kernel and initrd for iSCSI connections. So any network setup that should ever be done on that device is set even before it exits the initrd. If I set it to be managed by NM, will NM try to manage it in any way? Can I set it to be seen, but still unmanaged? Or maybe I could get NM to always output a connected status instead of a no-connection which triggers firefox offline mode, etc. (should the connection be lost, well, then NM won't be able to detect it anyway due to being frozen on the first page touch). Yes, if you set it to be managed by NM, NM will touch it, and that's probably not what you want. The boot-from-iscsi/fcoe problem is known, and something I will be spending time on in the near future. But at the moment, you might be better off turning NM off on these devices (chkconfig NetworkManager off) and letting the old 'network' service handle them. Dan Sorry if it's a common question, and my lack of understanding of NM, but I couldn't find any similar problems in the archives recently... Best regard. David This message was sent using IMP, the Internet Messaging Program. ___ 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: Novacom GNS-60IU - how to add support
On Sun, 2009-04-26 at 23:18 +0400, Alex Williams wrote: Depends on how odd the modem is, what sort of initialization it requires, and how screwed up the ISP's PPP server is. I haven't started to look into this yet, but I do remember a lot of variation back in the late 90s with ISP authentication procedures. For starters we just go with simple I think. What sort of wvdial config do you have for it? http://pastebin.ca/1403580 - that's all what you need to get it working with wvdial. It's a modern digital GPRS/EDGE modem with old style modem emulation (I think so :) )... Ok, that sounds like any normal 3G modem, not actually a POTS modem :) What does AT+GCAP return for the device, and what driver does it use? cdc-acm? What are the USB IDs of it? I'm also have Huawei E220 3G UMTS/HSDPA USB modem - it working fine with Ubuntu 9.04 and NetworkManager. But I need to watch signal level and other statistics - how to do that in NetworkManager? If this is not implemented in NetworkManager - I thinking about to implement it in future... but do not have free time... It's implemented on NM master using ModemManager; the NM 0.7.x infrastructure isn't flexible enough to do it currently. So NM 0.7.x probably won't get this functionality, but NM 0.8 will. You could write a small applet that just does AT+CSQ on a secondary port periodically and converts that from the GSM notation to suitable signal bars. NM 0.7.x shouldn't touch secondary USB interfaces at this time. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network manager Question
On Tue, Apr 28, 2009 at 5:45 PM, Craig fasteliteprogram...@yahoo.com wrote: NetworkManager: info starting... NetworkManager: WARN nm_dbus_manager_start_service(): Could not acquire the NetworkManager service as it is already taken. NetworkManager: WARN main(): Failed to start the dbus service. NetworkManager: info exiting (error) This means you didn't stop the NetworkManager service prior to issuing this command. You can't run two copies of NM in parallel. -- Patryk Zawadzki ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network manager Question
How do i do that? --- On Tue, 4/28/09, Patryk Zawadzki pat...@pld-linux.org wrote: From: Patryk Zawadzki pat...@pld-linux.org Subject: Re: network manager Question To: Craig fasteliteprogram...@yahoo.com Cc: Dan Williams d...@redhat.com, networkmanager-list@gnome.org Date: Tuesday, April 28, 2009, 10:54 AM On Tue, Apr 28, 2009 at 5:45 PM, Craig fasteliteprogram...@yahoo.com wrote: NetworkManager: info starting... NetworkManager: WARN nm_dbus_manager_start_service(): Could not acquire the NetworkManager service as it is already taken. NetworkManager: WARN main(): Failed to start the dbus service. NetworkManager: info exiting (error) This means you didn't stop the NetworkManager service prior to issuing this command. You can't run two copies of NM in parallel. -- Patryk Zawadzki ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problem with creating a new wireless network feature
On Sun, 2009-04-26 at 15:02 +0200, Ali Servet Donmez wrote: On Wed, 2009-04-08 at 15:21 -0400, Dan Williams wrote: [...] /var/log/daemon.log or /var/log/NetworkManager.log would be useful. Dan, sorry for waaay too late reply. Below I'll paste all logging info that I could capture: So this looks like the problem Apr 26 14:46:20 leilam dnsmasq[6434]: failed to bind listening socket for 10.42.43.1: Address already in use Apr 26 14:46:20 leilam dnsmasq[6434]: FAILED to start up I wonder if there's still a dnsmasq running bound to that address? Then at some point, your ipw2200 card goes off into the weeds: Apr 26 14:47:04 leilam kernel: [ 776.689496] ipw2200: Failed to send SYSTEM_CONFIG: Already sending a command. what kernel version and what ipw2200 firmware version? dan == Enabling wireless == daemon.log -- Apr 26 14:43:03 leilam NetworkManager: info Wireless now enabled by radio killswitch Apr 26 14:43:03 leilam NetworkManager: WARN nm_device_wifi_set_enabled(): not in expected unavailable state! Apr 26 14:43:03 leilam NetworkManager: info (eth1): device state change: 2 - 3 Apr 26 14:43:03 leilam NetworkManager: info (eth1): supplicant interface state change: 1 - 2. syslog -- Apr 26 14:43:03 leilam NetworkManager: info Wireless now enabled by radio killswitch Apr 26 14:43:03 leilam NetworkManager: WARN nm_device_wifi_set_enabled(): not in expected unavailable state! Apr 26 14:43:03 leilam NetworkManager: info (eth1): device state change: 2 - 3 Apr 26 14:43:03 leilam NetworkManager: info (eth1): supplicant interface state change: 1 - 2. == Creating New Wireless Network | Network Name: test | Wireless Security: None == syslog -- Apr 26 14:46:18 leilam NetworkManager: info Activation (eth1) starting connection 'test' Apr 26 14:46:18 leilam NetworkManager: info (eth1): device state change: 3 - 4 Apr 26 14:46:18 leilam NetworkManager: info Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled... Apr 26 14:46:18 leilam NetworkManager: info Activation (eth1) Stage 1 of 5 (Device Prepare) started... Apr 26 14:46:18 leilam NetworkManager: info Activation (eth1) Stage 2 of 5 (Device Configure) scheduled... Apr 26 14:46:18 leilam NetworkManager: info Activation (eth1) Stage 1 of 5 (Device Prepare) complete. Apr 26 14:46:18 leilam NetworkManager: info Activation (eth1) Stage 2 of 5 (Device Configure) starting... Apr 26 14:46:18 leilam NetworkManager: info (eth1): device state change: 4 - 5 Apr 26 14:46:18 leilam NetworkManager: info Activation (eth1/wireless): connection 'test' requires no security. No secrets needed. Apr 26 14:46:18 leilam NetworkManager: info Config: added 'ssid' value 'test' Apr 26 14:46:18 leilam NetworkManager: info Config: added 'mode' value '1' Apr 26 14:46:18 leilam NetworkManager: info Config: added 'frequency' value '2412' Apr 26 14:46:18 leilam NetworkManager: info Config: added 'key_mgmt' value 'NONE' Apr 26 14:46:18 leilam NetworkManager: info Activation (eth1) Stage 2 of 5 (Device Configure) complete. Apr 26 14:46:18 leilam NetworkManager: info Config: set interface ap_scan to 2 Apr 26 14:46:18 leilam kernel: [ 731.141897] firmware: requesting ipw2200-ibss.fw Apr 26 14:46:18 leilam NetworkManager: info (eth1): supplicant connection state change: 1 - 2 Apr 26 14:46:18 leilam NetworkManager: info (eth1): supplicant connection state change: 2 - 3 Apr 26 14:46:19 leilam kernel: [ 731.798637] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready Apr 26 14:46:19 leilam NetworkManager: info (eth1): supplicant connection state change: 3 - 4 Apr 26 14:46:19 leilam NetworkManager: info (eth1): supplicant connection state change: 4 - 7 Apr 26 14:46:19 leilam NetworkManager: info Activation (eth1/wireless) Stage 2 of 5 (Device Configure) successful. Connected to wireless network 'test'. Apr 26 14:46:19 leilam NetworkManager: info Activation (eth1) Stage 3 of 5 (IP Configure Start) scheduled. Apr 26 14:46:19 leilam NetworkManager: info Activation (eth1) Stage 3 of 5 (IP Configure Start) started... Apr 26 14:46:19 leilam NetworkManager: info (eth1): device state change: 5 - 7 Apr 26 14:46:19 leilam NetworkManager: info Activation (eth1) Stage 4 of 5 (IP Configure Get) scheduled... Apr 26 14:46:19 leilam NetworkManager: info Activation (eth1) Stage 3 of 5 (IP Configure Start) complete. Apr 26 14:46:19 leilam
Re: how can I disconnect?
That sounds good! If you plan to keep the device connected when switching it to manual mode (which seems to be the most intuitive way) you could implement a way to disconnect from a selected network near the corresponding item in the list such as in the image attached (which also seems the most intuitive way to disconnect to a network). the disconnect of course would go in every connection type, not only wireless attachment: disconnect.jpg___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Networkmanager and Bridges
On Sun, 2009-04-26 at 14:20 +0200, Tomáš Mudruňka wrote: In the todays boom of virtualization it should be nice if network manager will be able to create bridges between networks. Something like the simple one-click ( TM ;-) ) method in ms windows ;) especially ability to share internet connection with some virtual tun/tap NICs and their network. First step is to be aware if some interface becomed part of bridge and use this bridge instead of this NIC for connection. Because in other case the network manager can't manipulate the interface in any way. Right; bridging is quite high on the to-do list and it's mostly a matter of implementation. Much better solution for connecting virtual machines to network/internet is to automatically set routing, arp, dhcp and dns for selected device to share network with them. maybe you can use dnsmasq software? This should be also usefull when sharing internet bandwith with some physical network or if you want to create ad-hoc network to give your mobile phone the internet access on the road. NM already supports that using dnsmasq and NAT/iptables actually; it doesn't necessarily require a bridge. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: how can I disconnect?
On Tue, 2009-04-28 at 17:59 +0200, Nicolò Chieffo wrote: That sounds good! It was something we'd tossed around; the only issues are UI issues so as not to confuse users. We would have to do a lot more thinking about how to fit this into the current applet menu, which isn't really built for this sort of thing at the moment. If you plan to keep the device connected when switching it to manual mode (which seems to be the most intuitive way) you could implement a way to disconnect from a selected network near the corresponding item in the list such as in the image attached (which also seems the most intuitive way to disconnect to a network). the disconnect of course would go in every connection type, not only wireless There's actually already a disconnect function in NM, but of course if you have connections that are marked autoconnect=true, they'll just get reactivated immediately. This would also block on some mechanism of saving the state of the device so that when you reboot, the state is preserved. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network manager Question
Whatever mechanism PLD (or whatever distro you're running) uses to start and stop sysv services. On fedora that's /sbin/service NetworkManager stop or System-Administration-Services, but other distros do it differently. The sledgehammer is (as root) killall -TERM NetworkManager, but that doesn't let the system clean up after itself. Dan On Tue, 2009-04-28 at 08:58 -0700, Craig wrote: How do i do that? --- On Tue, 4/28/09, Patryk Zawadzki pat...@pld-linux.org wrote: From: Patryk Zawadzki pat...@pld-linux.org Subject: Re: network manager Question To: Craig fasteliteprogram...@yahoo.com Cc: Dan Williams d...@redhat.com, networkmanager-list@gnome.org Date: Tuesday, April 28, 2009, 10:54 AM On Tue, Apr 28, 2009 at 5:45 PM, Craig fasteliteprogram...@yahoo.com wrote: NetworkManager: info starting... NetworkManager: WARN nm_dbus_manager_start_service(): Could not acquire the NetworkManager service as it is already taken. NetworkManager: WARN main(): Failed to start the dbus service. NetworkManager: info exiting (error) This means you didn't stop the NetworkManager service prior to issuing this command. You can't run two copies of NM in parallel. -- Patryk Zawadzki ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How does network manager read rfkill ?
On Sat, 2009-04-25 at 00:45 +0300, Maxim Levitsky wrote:
On Fri, 2009-04-24 at 12:49 -0400, Dan Williams wrote:
On Fri, 2009-04-24 at 18:16 +0300, Maxim Levitsky wrote:
On Fri, 2009-04-24 at 11:06 -0400, Dan Williams wrote:
On Thu, 2009-04-23 at 22:35 +0300, Maxim Levitsky wrote:
On Thu, 2009-04-23 at 07:15 -0400, Dan Williams wrote:
On Thu, 2009-04-23 at 02:16 -0400, eye zak wrote:
Hi,
I am writing low-level rfkill support in the ath5k driver in
compat-wireless-2.6, and I am wondering how network manager knows
about my rfkill device ?
Hal recognizes it no problem and broadcasts an event on state
change,
and tracks the current state. But netowork manager (jaunty-latest)
does not notice it.
NM finds all devices in HAL with the capability 'killswitch', and
polls
them every 6 seconds to find out if any of them return 0 for
GetPower.
If any do, it assumes rfkill. Are you sure NM is allowed to talk
to HAL
on your distribution? Some distros like Debian use different D-Bus
permissions styles, and if those are wrong in
the /etc/dbus-1/system.d/NetworkManager.conf, NM may not be able to
talk
to HAL and get the killsiwtch state.
Dan
Or, it currently ignores platform kill switches, like acer-wmi
Do those rfkill switches expose themselves via HAL? If so, then
NetworkManager is expected to work with them. If not, then those need
to either (a) be ported to the kernel's rfkill subsystem in which case
they will be supported by HAL 0.5.12 automatically, or (b) get HAL
support otherwise.
Obviously (a) is preferred.
ma...@maxim-laptop:~$ hald --version
HAL package version: 0.5.12
I tried acer-wmi, and NM doesn't see it.
It does expose normal rfkill interface
What distro? Can you attach the lshal bits for all killswitches
contained in 'lshal' ?
Dan
Now I use ubuntu 9.04, but it was always present.
udi =
'/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_wireless_wlan'
info.addons.singleton = {'hald-addon-rfkill-killswitch'} (string list)
info.capabilities = {'killswitch'} (string list)
info.category = 'killswitch' (string)
info.interfaces = {'org.freedesktop.Hal.Device.KillSwitch'} (string list)
info.parent = '/org/freedesktop/Hal/devices/platform_acer_wmi' (string)
info.product = 'acer-wireless wlan Killswitch' (string)
info.subsystem = 'rfkill' (string)
info.udi =
'/org/freedesktop/Hal/devices/platform_acer_wmi_rfkill_acer_wireless_wlan'
(string)
killswitch.access_method = 'rfkill' (string)
killswitch.name = 'acer-wireless' (string)
killswitch.state = 1 (0x1) (int)
killswitch.type = 'wlan' (string)
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = 'rfkill' (string)
linux.sysfs_path = '/sys/devices/platform/acer-wmi/rfkill/rfkill1'
(string)
udi = '/org/freedesktop/Hal/devices/pci_8086_4222_rfkill_3945BG_wlan'
info.addons.singleton = {'hald-addon-rfkill-killswitch'} (string list)
info.capabilities = {'killswitch'} (string list)
info.category = 'killswitch' (string)
info.interfaces = {'org.freedesktop.Hal.Device.KillSwitch'} (string list)
info.parent = '/org/freedesktop/Hal/devices/pci_8086_4222' (string)
info.product = '3945BG wlan Killswitch' (string)
info.subsystem = 'rfkill' (string)
info.udi =
'/org/freedesktop/Hal/devices/pci_8086_4222_rfkill_3945BG_wlan' (string)
info.vendor = 'Intel Corporation' (string)
killswitch.access_method = 'rfkill' (string)
killswitch.name = '3945BG' (string)
killswitch.state = 1 (0x1) (int)
killswitch.type = 'wlan' (string)
linux.hotplug_type = 2 (0x2) (int)
linux.subsystem = 'rfkill' (string)
linux.sysfs_path =
'/sys/devices/pci:00/:00:1c.3/:06:00.0/rfkill/rfkill0' (string)
Last time, a week ago or so, I installed ubuntu 9.04
I disabled rfkill support in iwl3945, loaded acer-wmi, and yet NM didn't see
the killswitch, even after a reboot
Do you ever get anything in syslog (wherever syslog directs the 'daemon'
facility) about Found radio killswitch ? If not, then we have to
do some more debugging, and if you can rebuild NM with a patch or two,
I'd be happy to help figure out where NM is going wrong. Your lshal
looks fine.
Dan
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disable/Ignore access point
On Fri, 2009-04-24 at 14:16 -0400, Derek Atkins wrote: Dan Williams d...@redhat.com writes: On Thu, 2009-04-23 at 11:29 -0400, Derek Atkins wrote: Dan Williams d...@redhat.com writes: On Mon, 2009-04-20 at 16:15 -0500, Bryan Duff wrote: My situation is that I have a number of accessible access points for me. I'll connect to the AP I want, but at some interval NetworkManager re-scans available AP's and picks an unencrypted AP (that I don't want). So I have to then, via nm-applet, reselect the AP I want to use. So if NM is connecting to it, you must have selected it sometime before. If you won't want to connect to it, you can remove its configuration in the connection editor, and NM won't connect to it automatically any more. That didn't work for me.. Even after removing all remnants NM still wanted to connect to a local linksys network, no matter what I told it. When you say NM, do you mean NetworkManager itself in the logs said it was trying to connect, or do you mean you saw the BSSID of the linksys ap in the results for iwconfig at some point? Was that linksys connection a system connection? Yes, I mean Network Manager itself connected to the linksys even though I erased it. I even stopped NM, killed nm-applet, killed gconf, deleted all the files, and restarted everything, and it *still* connected to the linksys network against my wishes. When you say killed gconf, you mean 'rm -rf ~/.gconf' and then 'killall -TERM gconfd-2' or something else? I shouldn't have any system connections.. At least I'm pretty sure I never set any up. How do I check? If you run the connection editor, you'll see all the connections defined on your system. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 2009-04-24 at 16:16 -0400, Paul Wouters wrote: On Fri, 24 Apr 2009, Dan Williams wrote: people want to get notifications in userland on tunnels failing, they should configure the ipsec tunnel to use Dead Peer Detection (RFC3706) Ok, how does that actually show up in userspace? What can we make the NM vpn plugin daemon listen for? You tell me. What infrastructure is there for NM? I know there is dbus, but I don't think that channel can be secured at all. Would unauthenticated announcements be okay? Does NM have any other listening or polling methods? D-Bus can certainly be secured. D-Bus security is based on a few different mechanisms; one of which is user-based authentication. So you can make sure that only the root user can access the D-Bus interface, or only a certain group, or only users determined to be at console (ie, physically present and not via SSH or remote X). Beyond that, finer-grained access control is accomplished with stuff like PolicyKit, but you probably don't need that. Otherwise, socket-based mechanisms (that user peer credentials to authenticate the remote UID, which is what D-Bus uses too) would be fine too, as long as that socket-based API was sane. I guess I would have assumed something like this would be available already via whack, but perhaps I misunderstand how the stack fits together. Dan Yeah there's support for this. Basically, you have two classes of connections: system and user. Just like OS X actually. User connections credentials and details are stored in the user session and do not survive fast-user-switch. System connections are stored outside of the user session, and thus are available before login and survive a fast user switch. So if you don't want your VPN to be avialable to everyone, you keep it as a user connection. If you don't care, you make it a system connection and available to all users as the UI checkbutton puts it. That's good. Paul ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Fri, 2009-04-24 at 16:40 -0400, Paul Wouters wrote: On Fri, 24 Apr 2009, Dan Williams wrote: Except for rekeying with OTP tokens like RSA SecurKey or whatever they are called. That's a pretty huge use-case where the authentication isn't the same the next time a reauth happens. Intentionally so of course. Those connections tend to use 8 hour plus IKE/IPsec SA lifetimes, so they basically never rekey. But you are right. There are two ways of handling this. Either you just bring down the IKE connection (while the IPsec SA is still up so packets still flow) and this triggers an event to NM so it can ask for the OTP and then rekey the IKE connection, or you kill the connection and let the user connect from scratch. The latter is mostly found in GUI software. Openswan currently does not have a method for signaling, but if we're building that in via dbus or something anyway, this becomes an easy possibility, and with no packet loss to the end user. Ideally the first thing you mentioned occurs, the daemon somehow signals NM that it needs new credentials, and pauses the connection for a bit until they are entered. I assume if the user isn't around to type in the password, then the connection should just die after a timeout since those resources won't be allocated forever on both sides (otherwise it's a nice DoS). We can (and should) handle this intelligently in the NM stack as long as there's supporting infrastructure in the VPN stack itself. Right. We pretty much ignore that problem right now anyway; whatever gets the highest priority in the routing table wins. That's not something that we can really fix, that's a VPN configuration problem for the user and their sysadmin, if any. Agreed. The largest problem with IPSec is that since it's half-kernel and half-daemon, there isn't necessarily something there (AFAIK) to alert NetworkManager to the presence of a dropped connection or something like that. If there is, that's great, lets use it and it'll be awesome. DPD RFC 3706. Though Openswan needs to signal this to NM. Openswan has settings for dpdtimeout, dppdelay= and dpdaction=. Actions can be to turn off the vpn or to try and restart it. You mean a daemon component, right? If there's a daemon watching the connection already, that's awesome, since then the notifications can be delivered somehow. There is. The IKE daemon always runs. I am not sure how familiar you are with IKE, so let me give an exec summary. The IKE daemon establish a command channel over which they agree IPsec paramters. These daemons always run. Once they agree something, they inform the kernel, which install the actual keying information along with lifetime information for the tunnel (in time units or in byte units) The kernel never talks to userland IKE, it only listens for it. IKE makes all the decisions. IKE is userland, which is the openswan pluto daemon. That entity will have to listen and talk to NM somehow. Excellent. That means (as I understand it) that since pluto has the whack-style control interface, we could use that for communication with the IKE daemon? That could work, yes. As long as connection setup, authentication, and reauthentication can all happen without using config files or statically stored on-disk secrets that sounds fine. Not yet, but that modification will be made for you. Excellent. Certificates should actually be stored on-disk or in a Certificate Store like NSS. Private keys should typically not be expected to be stored on-disk since they may exist in a PKCS#11 device or some other location. Openswan 2.6.21 has limited support for NSS. The current development release 2.6.22dr1 has (full?) NSS support. So this should not be a problem anymore. Yeah, though we have a general problem in that we don't have a coherent story on Linux for a good system certificate store. That's not openswan's problem but something we need to solve as a whole. In the future that means passing not certificate/key data, but a token that's used as a reference into the NSS certificate store to get the actual certificate (which might be on a card) or which tells NSS which private key (which might also be on a card and not retrievable) to use for encryption/decryption. This functionaliy is missing and will need to be added, though it should be a relatively simple change. XAUTH credentials can already be passed in via whack. xl2tpd (the client to start l2tp after ipsec is established) takes commands (including passwwords) on a named pipe, so this should also not be a problem. Hmm, I'll have to dig in the l2tp stuff a bit more. I'll need to check that too. Currently, from the unit test in openswan-2.x.y/testing/pluto/*l2tp* I only see us do: echo c server /var/run/l2tp-control I think this is taking the user/password information from /etc/ppp, so if you have a system in place for pppd already, I
Re: more than one default gw route
Dan Williams wrote: On Tue, 2009-04-28 at 17:47 +0200, Nicolò Chieffo wrote: So do you confirm that having more that one default route to gateway (at the same time) will break things down? Oh, it won't break things down at all. But the first default route in the routing table will be the one that gets used for new outgoing connections. So it's pretty pointless to have more than one at a time. Only one can truly the be the default route, and if you have more than one, the lower-priority ones are more or less ignored by the kernel entirely. Just to clarify a bit futher :) The route command will show the metric for each installed route. For duplicate routes, the one with the lowest metric is used. Thanks Roy ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Disable/Ignore access point
Quoting Dan Williams d...@redhat.com: Yes, I mean Network Manager itself connected to the linksys even though I erased it. I even stopped NM, killed nm-applet, killed gconf, deleted all the files, and restarted everything, and it *still* connected to the linksys network against my wishes. When you say killed gconf, you mean 'rm -rf ~/.gconf' and then 'killall -TERM gconfd-2' or something else? gconftool-2 --shutdown Then rm -rf ~/.gconf/.../linksys (I removed the linksys directory in the wireless networks list) I shouldn't have any system connections.. At least I'm pretty sure I never set any up. How do I check? If you run the connection editor, you'll see all the connections defined on your system. And there are a bunch of Auto ... networks there, but not in any particular order which makes it hard to find one in particular. Dan -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: more than one default gw route
I like the idea of the MAC-detection or ping functionality, might I recommend using httping it tends to appear more friendly to the general public and is less likely to be dropped than a ping by networks. The method of having multiply default routes with different weights is not the same as having two *active* default routes. If two defaults routes were active and load balancing was to be performed it would have to be balanced per (src ip,dest ip) tuple flows so that related connections were not confused. I would love to see fail-over, as I'm sure many others would. -- John On Tue, Apr 28, 2009 at 12:09 PM, Dan Williams d...@redhat.com wrote: On Tue, 2009-04-28 at 17:47 +0200, Nicolò Chieffo wrote: So do you confirm that having more that one default route to gateway (at the same time) will break things down? Oh, it won't break things down at all. But the first default route in the routing table will be the one that gets used for new outgoing connections. So it's pretty pointless to have more than one at a time. Only one can truly the be the default route, and if you have more than one, the lower-priority ones are more or less ignored by the kernel entirely. Dan If so, I will wait for a graphic way to disconnect devices separately. Is this in your plans? ___ 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: periodic_update(): Roamed ...
Dan Williams wrote: On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote: Dan Williams wrote: On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. How would I check this? Should it be obvious from iwlist scan ? That returns the current AP along with the other visible ones. Also, reviewing the comments in bug 291760, this problem is not just isolated to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, ipw2100, rtl8187, and b43, across multiple kernel and driver revisions. As such it seems unlikely to be the drivers' fault. Depends; it might show up in that scan, or it might not. If you can reliably get it to show up every time, that's great. But until 2.6.30, mac80211-based drivers would not always return the current AP. And some of the older drivers don't either, though fullmac drivers are more likely to be OK there. If you already know for a fact that certain drivers are incompatible with NM, it seems you should be documenting that in your release notes or something. Or, you should be maintaining a list of tested known-to-work drivers. There is one window where NM wouldn't be able to find the AP; if NM just did a scan, and then the card reassociates to a different AP that's not in the scan list, and doesn't send an GIWSCAN event so that the AP list gets pulled (ipw2x00 do this, other drivers might not), then when NM goes to pull the BSSID off the card, the scan list doesn't contain the current AP. What NM should be doing here is to request that the supplicant grab the scan list again when it sees a BSSID it doesn't know about, but that's somewhat complicated. There must be more cases than this, because there are no other APs for my card to associate to. (They're all secured with WEP or WPA, and I only have credentials for mine.) The only reason I ever see the card reassociate at all is due to NM's scanning; with that patched out it just stays associated. If the driver doesn't return the frequency of the BSSID in the scan results, or that frequency doesn't match what the card reports from SIOCGIWFREQ, then NM also can come up with (none). Check that the information from an 'iwlist scan' for that BSSID matches what 'iwconfig' reports when associated to that specific AP. So in conclusion there are actual driver bugs; (a) not all drivers scan results contain the currently associated AP in every scan, and (b) not all drivers emit scan results events when they associate to a new AP that's not already in the scan list, and finally (c) some drivers are just busted and return wrong channel information. Pretty sure (c) is not the case here, the info from iwlist scan and iwconfig all matches. (b) won't happen in my current environment, so I can't test one way or another. (a) doesn't appear to happen when I look, but I have no idea how many scans are needed before the symptom occurs. It seems to me that blaming the driver is not particularly useful unless you can provide a procedure or script to demonstrate the driver bugs. In the meantime, that whole spectrum of drivers is out there and people are trying to use them. And except for whatever NM's undocumented expectations, those cards and drivers work fine. Since only NM causes problems, it's your responsibility to either help identify the problems so the driver writers can fix them, or make NM work despite those problems. E.g., if you know that scans return unreliable information, then *stop relying on the scan results*. Clearly the driver can tell you if it's associated or not. Assuming that the association is gone because the current AP doesn't show up in the current scan list, when you know that scans can be incomplete, is stupid. Likewise, continual scanning seems to be counterproductive. The impact it has on network throughput is significant: 64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.57
Re: umts connection closed after succefull ppp negotiation
On Tue, 2009-04-28 at 11:46 -0400, Dan Williams wrote: On Mon, 2009-04-27 at 14:14 +0200, Alessandro Bono wrote: Hi I'm testing my new umts connection but seems there are problem with NM on my system I tried with two different modem (onda et505up and onda mt503hsa) with the same result warning pppd_timed_out(): Looks like pppd didn't initialize our dbus module not seems influence the result, it's possible to remove this warning changing a dbus acl but without any difference below full log of a connection with pppd debug enabled and some info of my system any idea how to debug or workaround this problem? Stop NM, then as root: NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon Hi Dan I tried as you suggest but not found nothing interesting just to be sure I tried with wvdial with this configuration [Dialer Defaults] Modem = /dev/ttyUSB2 Baud = 460800 Init1 = ATZ Init2 = AT+CGDCONT=1,IP,ibox.tim.it,,0,0 ISDN = 0 Modem Type = Analog Modem Carrier Check = no Phone = *99# Username = '' Password = '' and connection works without problem below a full log with NM_PPP_DEBUG (I tried with and without username and password) NetworkManager: info Activation (ttyUSB2) starting connection 'TIM' NetworkManager: info (ttyUSB2): device state change: 3 - 4 NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) started... NetworkManager: debug [1240936873.552324] nm_serial_device_open(): (ttyUSB2) opening device... NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) complete. NetworkManager: info (ttyUSB2): powering up... NetworkManager: info Registered on Home network NetworkManager: info Associated with network: +COPS: 0,0,Telecom Italia Mobile,2 NetworkManager: info Connected, Woo! NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) scheduled... NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) starting... NetworkManager: info (ttyUSB2): device state change: 4 - 5 NetworkManager: info Starting pppd connection NetworkManager: debug [1240936875.322454] nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock nodefaultroute debug ttyUSB2 noipdefault noauth usepeerdns lcp-echo-failure 0 lcp-echo-interval 0 ipparam /org/freedesktop/NetworkManager/PPP/1 plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so loaded. NetworkManager: debug [1240936875.342187] nm_ppp_manager_start(): ppp started with pid 7319 NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) complete. using channel 2 Using interface ppp0 Connect: ppp0 -- /dev/ttyUSB2 sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0x2874a5b2 pcomp accomp] rcvd [LCP ConfReq id=0x3 asyncmap 0x0 auth chap MD5 magic 0x117ef87 pcomp accomp] sent [LCP ConfAck id=0x3 asyncmap 0x0 auth chap MD5 magic 0x117ef87 pcomp accomp] rcvd [LCP ConfAck id=0x1 asyncmap 0x0 magic 0x2874a5b2 pcomp accomp] rcvd [LCP DiscReq id=0x4 magic=0x117ef87] rcvd [CHAP Challenge id=0x1 3824bee55e4e3c26ee103d41b89a2210, name = UMTS_CHAP_SRVR] ** (process:7319): WARNING **: Could not get secrets: Rejected send
Re: Generic IPSEC vpn plugin
On Tue, 2009-04-28 at 12:32 -0400, Dan Williams wrote: That's fine, since NM (and the VPN plugin) would be running as root for the time being. David woodhouse wants to make them not run as root, but that might only happen for the VPN daemons that don't actually need root. Sounds like for now, the openswan one would. We already have that working for OpenConnect. It's optional, and I haven't changed any other VPN dæmons to do it. -- dwmw2 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generic IPSEC vpn plugin
On Tue, 2009-04-28 at 18:35 +0100, David Woodhouse wrote: On Tue, 2009-04-28 at 12:32 -0400, Dan Williams wrote: That's fine, since NM (and the VPN plugin) would be running as root for the time being. David woodhouse wants to make them not run as root, but that might only happen for the VPN daemons that don't actually need root. Sounds like for now, the openswan one would. We already have that working for OpenConnect. It's optional, and I haven't changed any other VPN dæmons to do it. I assume that would mean the vpn daemon opening the pluto socket before dropping privs, right? Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: umts connection closed after succefull ppp negotiation
On Tue, 2009-04-28 at 18:42 +0200, Alessandro Bono wrote: On Tue, 2009-04-28 at 11:46 -0400, Dan Williams wrote: On Mon, 2009-04-27 at 14:14 +0200, Alessandro Bono wrote: Hi I'm testing my new umts connection but seems there are problem with NM on my system I tried with two different modem (onda et505up and onda mt503hsa) with the same result warning pppd_timed_out(): Looks like pppd didn't initialize our dbus module not seems influence the result, it's possible to remove this warning changing a dbus acl but without any difference below full log of a connection with pppd debug enabled and some info of my system any idea how to debug or workaround this problem? Stop NM, then as root: NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon Hi Dan I tried as you suggest but not found nothing interesting just to be sure I tried with wvdial with this configuration What dbus version? Dan [Dialer Defaults] Modem = /dev/ttyUSB2 Baud = 460800 Init1 = ATZ Init2 = AT+CGDCONT=1,IP,ibox.tim.it,,0,0 ISDN = 0 Modem Type = Analog Modem Carrier Check = no Phone = *99# Username = '' Password = '' and connection works without problem below a full log with NM_PPP_DEBUG (I tried with and without username and password) NetworkManager: info Activation (ttyUSB2) starting connection 'TIM' NetworkManager: info (ttyUSB2): device state change: 3 - 4 NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) started... NetworkManager: debug [1240936873.552324] nm_serial_device_open(): (ttyUSB2) opening device... NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) complete. NetworkManager: info (ttyUSB2): powering up... NetworkManager: info Registered on Home network NetworkManager: info Associated with network: +COPS: 0,0,Telecom Italia Mobile,2 NetworkManager: info Connected, Woo! NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) scheduled... NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) starting... NetworkManager: info (ttyUSB2): device state change: 4 - 5 NetworkManager: info Starting pppd connection NetworkManager: debug [1240936875.322454] nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock nodefaultroute debug ttyUSB2 noipdefault noauth usepeerdns lcp-echo-failure 0 lcp-echo-interval 0 ipparam /org/freedesktop/NetworkManager/PPP/1 plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so loaded. NetworkManager: debug [1240936875.342187] nm_ppp_manager_start(): ppp started with pid 7319 NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) complete. using channel 2 Using interface ppp0 Connect: ppp0 -- /dev/ttyUSB2 sent [LCP ConfReq id=0x1 asyncmap 0x0 magic 0x2874a5b2 pcomp accomp] rcvd [LCP ConfReq id=0x3 asyncmap 0x0 auth chap MD5 magic 0x117ef87 pcomp accomp] sent [LCP ConfAck id=0x3 asyncmap 0x0 auth chap MD5 magic 0x117ef87 pcomp accomp] rcvd [LCP ConfAck id=0x1 asyncmap 0x0 magic 0x2874a5b2 pcomp accomp]
Re: periodic_update(): Roamed ...
On Tue, 2009-04-28 at 09:42 -0700, Howard Chu wrote: Dan Williams wrote: On Fri, 2009-04-24 at 15:18 -0700, Howard Chu wrote: Dan Williams wrote: On Mon, 2009-04-20 at 15:37 -0700, Howard Chu wrote: Howard Chu wrote: This is probably more related to the ath9k driver, but I wanted to start here in case anyone is familiar with it. I've been seeing this for the past couple months, and I just now rebuilt NM fresh from git and it's still happening: I seem to have ruled out the driver; doing a kill -9 on NetworkManager so it doesn't have the opportunity to tear down the connection on exit, shows that the wifi connection works perfectly once NetworkManager is gone. No disassociation messages in dmesg, no pauses in ssh sessions, etc. Don't rule out the driver. Does the driver always return the currently associated AP in the scan list? If not, you might hit this. And the driver is being stupid, because of *course* the AP you're currently connected to should always be in the scan list, unless you're no longer connected to it. The code in NM grabs the SSID BSSID on a 6 second timer, and tries to find that AP in the scan list. If it can't find it (because the driver didn't return that AP in the scan list) then it reports none. If that's your problem, it's a driver problem. How would I check this? Should it be obvious from iwlist scan ? That returns the current AP along with the other visible ones. Also, reviewing the comments in bug 291760, this problem is not just isolated to the ath9k driver. It's also being reported for ath5k, wl, iwl3945, ipw2100, rtl8187, and b43, across multiple kernel and driver revisions. As such it seems unlikely to be the drivers' fault. Depends; it might show up in that scan, or it might not. If you can reliably get it to show up every time, that's great. But until 2.6.30, mac80211-based drivers would not always return the current AP. And some of the older drivers don't either, though fullmac drivers are more likely to be OK there. If you already know for a fact that certain drivers are incompatible with NM, it seems you should be documenting that in your release notes or something. Or, you should be maintaining a list of tested known-to-work drivers. There is one window where NM wouldn't be able to find the AP; if NM just did a scan, and then the card reassociates to a different AP that's not in the scan list, and doesn't send an GIWSCAN event so that the AP list gets pulled (ipw2x00 do this, other drivers might not), then when NM goes to pull the BSSID off the card, the scan list doesn't contain the current AP. What NM should be doing here is to request that the supplicant grab the scan list again when it sees a BSSID it doesn't know about, but that's somewhat complicated. There must be more cases than this, because there are no other APs for my card to associate to. (They're all secured with WEP or WPA, and I only have credentials for mine.) The only reason I ever see the card reassociate at all is due to NM's scanning; with that patched out it just stays associated. If the driver doesn't return the frequency of the BSSID in the scan results, or that frequency doesn't match what the card reports from SIOCGIWFREQ, then NM also can come up with (none). Check that the information from an 'iwlist scan' for that BSSID matches what 'iwconfig' reports when associated to that specific AP. So in conclusion there are actual driver bugs; (a) not all drivers scan results contain the currently associated AP in every scan, and (b) not all drivers emit scan results events when they associate to a new AP that's not already in the scan list, and finally (c) some drivers are just busted and return wrong channel information. Pretty sure (c) is not the case here, the info from iwlist scan and iwconfig all matches. (b) won't happen in my current environment, so I can't test one way or another. (a) doesn't appear to happen when I look, but I have no idea how many scans are needed before the symptom occurs. You can run NM with: NM_ACTIVE_AP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon and get a lot more info about what's happening here and why the active AP isn't found in the scan list. Any chance you can do that and post the results? Dan It seems to me that blaming the driver is not particularly useful unless you can provide a procedure or script to demonstrate the driver bugs. In the meantime, that whole spectrum of drivers is out there and people are trying to use them. And except for whatever NM's undocumented expectations, those cards and drivers work fine. Since only NM causes problems, it's your responsibility to either help identify the problems so the driver writers can fix them, or make NM work despite those problems. E.g., if you know that scans return unreliable information,
Re: more than one default gw route
The kind of fail-over detection I was thinking of is focused on the use case of: (1) a machine with both a wired and wireless connection, on a single network with a single gateway (2) the user sometimes disconnects the wired connection and takes the laptop somewhere else For this use case, you would not need any kind of continual ping. (if you were trying to have redundant ISPs, that would be a separate issue.) You would only need ARP to detect if the router is still up during a failover. For other use cases, I agree, you wouldn't want to limit yourself to ICMP pings. I'm still pondering the potential security issues of a setup like this. Someone would have to set up a wireless network to look just like your wired network, and spoof the router MAC. But they wouldn't be able to pass the bridge test. That is, you could confirm that it is the same network by sending out a packet on one interface and confirming that you receive it on the other. Mike On Tue, Apr 28, 2009 at 9:35 AM, John Mahoney jmaho...@waav.com wrote: I like the idea of the MAC-detection or ping functionality, might I recommend using httping it tends to appear more friendly to the general public and is less likely to be dropped than a ping by networks. The method of having multiply default routes with different weights is not the same as having two *active* default routes. If two defaults routes were active and load balancing was to be performed it would have to be balanced per (src ip,dest ip) tuple flows so that related connections were not confused. I would love to see fail-over, as I'm sure many others would. -- John On Tue, Apr 28, 2009 at 12:09 PM, Dan Williams d...@redhat.com wrote: On Tue, 2009-04-28 at 17:47 +0200, Nicolò Chieffo wrote: So do you confirm that having more that one default route to gateway (at the same time) will break things down? Oh, it won't break things down at all. But the first default route in the routing table will be the one that gets used for new outgoing connections. So it's pretty pointless to have more than one at a time. Only one can truly the be the default route, and if you have more than one, the lower-priority ones are more or less ignored by the kernel entirely. Dan If so, I will wait for a graphic way to disconnect devices separately. Is this in your plans? ___ 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 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: more than one default gw route
That would be required to have your computer persist active connections from the old interface to the new interface. Eventually, the connections will timeout and restart. Your also assuming both connections have mac addresses, this is not always the case with cell modems using ppp, which would be where fail over truly becomes very useful. It would be nice to have a data card always on, but only used as a last resort. -- John On Tue, Apr 28, 2009 at 4:20 PM, Mike Pontillo ponti...@gmail.com wrote: The kind of fail-over detection I was thinking of is focused on the use case of: (1) a machine with both a wired and wireless connection, on a single network with a single gateway (2) the user sometimes disconnects the wired connection and takes the laptop somewhere else For this use case, you would not need any kind of continual ping. (if you were trying to have redundant ISPs, that would be a separate issue.) You would only need ARP to detect if the router is still up during a failover. For other use cases, I agree, you wouldn't want to limit yourself to ICMP pings. I'm still pondering the potential security issues of a setup like this. Someone would have to set up a wireless network to look just like your wired network, and spoof the router MAC. But they wouldn't be able to pass the bridge test. That is, you could confirm that it is the same network by sending out a packet on one interface and confirming that you receive it on the other. Mike On Tue, Apr 28, 2009 at 9:35 AM, John Mahoney jmaho...@waav.com wrote: I like the idea of the MAC-detection or ping functionality, might I recommend using httping it tends to appear more friendly to the general public and is less likely to be dropped than a ping by networks. The method of having multiply default routes with different weights is not the same as having two *active* default routes. If two defaults routes were active and load balancing was to be performed it would have to be balanced per (src ip,dest ip) tuple flows so that related connections were not confused. I would love to see fail-over, as I'm sure many others would. -- John On Tue, Apr 28, 2009 at 12:09 PM, Dan Williams d...@redhat.com wrote: On Tue, 2009-04-28 at 17:47 +0200, Nicolò Chieffo wrote: So do you confirm that having more that one default route to gateway (at the same time) will break things down? Oh, it won't break things down at all. But the first default route in the routing table will be the one that gets used for new outgoing connections. So it's pretty pointless to have more than one at a time. Only one can truly the be the default route, and if you have more than one, the lower-priority ones are more or less ignored by the kernel entirely. Dan If so, I will wait for a graphic way to disconnect devices separately. Is this in your plans? ___ 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 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: more than one default gw route
Right. So that example is a different use case than mine, since it involves two ISPs, two different gateways, etc. Then the problem becomes which of the two potential gateways that I have is able to access the internet, which is a somewhat harder problem (though not unsolvable).Then you have to start worrying about real pings | http requests | whatever, and the resulting potential for DoS. You also have to worry about corporate firewalls, HTTP proxies, etc, or you might start quickly running up the bill on your 3G card. Mike On Tue, Apr 28, 2009 at 1:36 PM, John Mahoney jmaho...@waav.com wrote: That would be required to have your computer persist active connections from the old interface to the new interface. Eventually, the connections will timeout and restart. Your also assuming both connections have mac addresses, this is not always the case with cell modems using ppp, which would be where fail over truly becomes very useful. It would be nice to have a data card always on, but only used as a last resort. -- John On Tue, Apr 28, 2009 at 4:20 PM, Mike Pontillo ponti...@gmail.com wrote: The kind of fail-over detection I was thinking of is focused on the use case of: (1) a machine with both a wired and wireless connection, on a single network with a single gateway (2) the user sometimes disconnects the wired connection and takes the laptop somewhere else For this use case, you would not need any kind of continual ping. (if you were trying to have redundant ISPs, that would be a separate issue.) You would only need ARP to detect if the router is still up during a failover. For other use cases, I agree, you wouldn't want to limit yourself to ICMP pings. I'm still pondering the potential security issues of a setup like this. Someone would have to set up a wireless network to look just like your wired network, and spoof the router MAC. But they wouldn't be able to pass the bridge test. That is, you could confirm that it is the same network by sending out a packet on one interface and confirming that you receive it on the other. Mike On Tue, Apr 28, 2009 at 9:35 AM, John Mahoney jmaho...@waav.com wrote: I like the idea of the MAC-detection or ping functionality, might I recommend using httping it tends to appear more friendly to the general public and is less likely to be dropped than a ping by networks. The method of having multiply default routes with different weights is not the same as having two *active* default routes. If two defaults routes were active and load balancing was to be performed it would have to be balanced per (src ip,dest ip) tuple flows so that related connections were not confused. I would love to see fail-over, as I'm sure many others would. -- John On Tue, Apr 28, 2009 at 12:09 PM, Dan Williams d...@redhat.com wrote: On Tue, 2009-04-28 at 17:47 +0200, Nicolò Chieffo wrote: So do you confirm that having more that one default route to gateway (at the same time) will break things down? Oh, it won't break things down at all. But the first default route in the routing table will be the one that gets used for new outgoing connections. So it's pretty pointless to have more than one at a time. Only one can truly the be the default route, and if you have more than one, the lower-priority ones are more or less ignored by the kernel entirely. Dan If so, I will wait for a graphic way to disconnect devices separately. Is this in your plans? ___ 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 ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[WISH] Make NM autodetect if it can reach the internet
It would be very nice to know if Internet is reachable or not. It could be done by pinging a server or a server from a list. (of course there is a risk of dos attack, running up the bill, etc) But, today, at least ubuntu _always_ uses ntpdate to update the time, each time I connect to the Internet. can't you integrate this into NM? Probably time is updated only once at connection, but still this at least will show if connection is active. Plus, you could add an 'optional' setting to ping a user specified server at, user specified interval. (disabled by default) What do you think? Best regards, Maxim Levitsky ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: umts connection closed after succefull ppp negotiation
On Tue, 2009-04-28 at 13:58 -0400, Dan Williams wrote: On Tue, 2009-04-28 at 18:42 +0200, Alessandro Bono wrote: On Tue, 2009-04-28 at 11:46 -0400, Dan Williams wrote: On Mon, 2009-04-27 at 14:14 +0200, Alessandro Bono wrote: Hi I'm testing my new umts connection but seems there are problem with NM on my system I tried with two different modem (onda et505up and onda mt503hsa) with the same result warning pppd_timed_out(): Looks like pppd didn't initialize our dbus module not seems influence the result, it's possible to remove this warning changing a dbus acl but without any difference below full log of a connection with pppd debug enabled and some info of my system any idea how to debug or workaround this problem? Stop NM, then as root: NM_PPP_DEBUG=1 /usr/sbin/NetworkManager --no-daemon Hi Dan I tried as you suggest but not found nothing interesting just to be sure I tried with wvdial with this configuration What dbus version? dpkg -l | grep dbus ii dbus 1.2.12-0ubuntu2 simple interprocess messaging system ii dbus-x11 1.2.12-0ubuntu2 simple interprocess messaging system (X11 de ii gstreamer-dbus-media-service 0.1.17-upstream-0ubuntu3 Media service for Ubuntu Mobile ii libdbus-1-31.2.12-0ubuntu2 simple interprocess messaging system ii libdbus-1-dev 1.2.12-0ubuntu2 simple interprocess messaging system (develo ii libdbus-1-qt3 0.9-0ubuntu1 dbus bindings for Qt 3 (backport of the Qt 4 ii libdbus-glib-1-2 0.80-3 simple interprocess messaging system (GLib-b ii libdbus-qt-1-1c2 0.62.git.20060814-2build1 simple interprocess messaging system (Qt-bas ii libndesk-dbus-glib1.0-cil 0.4.1-1ubuntu1 CLI implementation of D-Bus (GLib mainloop i ii libndesk-dbus1.0-cil 0.6.0-1ubuntu1 CLI implementation of D-Bus ii libnet-dbus-perl 0.33.6-1build2 Extension for the DBus bindings ii libpolkit-dbus20.9-2ubuntu1 library for accessing PolicyKit via D-Bus ii libqt4-dbus4.5.0-0ubuntu4 Qt 4 D-Bus module ii libstrigiqtdbusclient0 0.6.4-0ubuntu2 library for writing D-Bus clients for Strigi ii python-dbus0.83.0-1ubuntu1 simple interprocess messaging system (Python ii python-qt4-dbus4.4.4-2ubuntu6 DBus Support for PyQt4 tell me if you need other information thanks Dan [Dialer Defaults] Modem = /dev/ttyUSB2 Baud = 460800 Init1 = ATZ Init2 = AT+CGDCONT=1,IP,ibox.tim.it,,0,0 ISDN = 0 Modem Type = Analog Modem Carrier Check = no Phone = *99# Username = '' Password = '' and connection works without problem below a full log with NM_PPP_DEBUG (I tried with and without username and password) NetworkManager: info Activation (ttyUSB2) starting connection 'TIM' NetworkManager: info (ttyUSB2): device state change: 3 - 4 NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) started... NetworkManager: debug [1240936873.552324] nm_serial_device_open(): (ttyUSB2) opening device... NetworkManager: info Activation (ttyUSB2) Stage 1 of 5 (Device Prepare) complete. NetworkManager: info (ttyUSB2): powering up... NetworkManager: info Registered on Home network NetworkManager: info Associated with network: +COPS: 0,0,Telecom Italia Mobile,2 NetworkManager: info Connected, Woo! NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) scheduled... NetworkManager: info Activation (ttyUSB2) Stage 2 of 5 (Device Configure) starting... NetworkManager: info (ttyUSB2): device state change: 4 - 5 NetworkManager: info Starting pppd connection NetworkManager: debug [1240936875.322454] nm_ppp_manager_start(): Command line: /usr/sbin/pppd nodetach lock nodefaultroute debug ttyUSB2 noipdefault noauth usepeerdns lcp-echo-failure 0 lcp-echo-interval 0 ipparam /org/freedesktop/NetworkManager/PPP/1 plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so Plugin /usr/lib/pppd/2.4.4/nm-pppd-plugin.so loaded.
