Re: NM disconnect after one hour with a wired network
Le 11/01/2011 02:44, Dan Williams a écrit : On Mon, 2011-01-10 at 20:36 +, Charles Cultien wrote: Le 10/01/2011 16:35, Larry Finger a écrit : On 01/09/2011 05:15 AM, Charles Cultien wrote: Hi, I have a very strange problem : I'm connected with the wired network of my university and each time, after one hour, Network Manager disconnect himself and didn't reconnect automatically. So I have to reconnect by myself evry hour and this is boring ! I don't know why and how change this. A dmesg didn't show anything (on the moment it disconnect). I'm using LInux Mint DEbian (so debian testing) with : Linux kernel 2.6.32-5-686 GNOME 2.30.2 Network Manager 0.8.1 I'am am behind a proxy (automatically given by the script htpp://proxyconf) and so the gnome proxy is configured. Thank you for helping and didn't hesitate asking for trying something or given more information. Does the listing produced by running 'iw event -t -f' show anything at the time of disconnect? Larry I run this command : nothing appears before, during and after. When the disconnect happens, what does 'dmesg' report at the bottom of the output? Dan dmesg didn't show anything. The only thing showed before any cut (printed only one time) is this line : [ 1310.768042] CE: hpet increasing min_delta_ns to 15000 nsec This can't be coming from my connection because with Windows I haven't such a cut (or maybe the cut but it reconnect automatically). Charles ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM disconnect after one hour with a wired network
On Tue, 2011-01-11 at 12:53 +, Charles Cultien wrote: Le 11/01/2011 02:44, Dan Williams a écrit : On Mon, 2011-01-10 at 20:36 +, Charles Cultien wrote: Le 10/01/2011 16:35, Larry Finger a écrit : On 01/09/2011 05:15 AM, Charles Cultien wrote: Hi, I have a very strange problem : I'm connected with the wired network of my university and each time, after one hour, Network Manager disconnect himself and didn't reconnect automatically. So I have to reconnect by myself evry hour and this is boring ! I don't know why and how change this. A dmesg didn't show anything (on the moment it disconnect). I'm using LInux Mint DEbian (so debian testing) with : Linux kernel 2.6.32-5-686 GNOME 2.30.2 Network Manager 0.8.1 I'am am behind a proxy (automatically given by the script htpp://proxyconf) and so the gnome proxy is configured. Thank you for helping and didn't hesitate asking for trying something or given more information. Does the listing produced by running 'iw event -t -f' show anything at the time of disconnect? Larry I run this command : nothing appears before, during and after. When the disconnect happens, what does 'dmesg' report at the bottom of the output? Dan dmesg didn't show anything. The only thing showed before any cut (printed only one time) is this line : [ 1310.768042] CE: hpet increasing min_delta_ns to 15000 nsec This can't be coming from my connection because with Windows I haven't such a cut (or maybe the cut but it reconnect automatically). Can you grab /var/log/messages or /var/log/daemon.log when you note the disconnect and paste/attach the last 100 lines or so? It could be a DHCP failure too. If 'dmesg' doesn't say anything it could either be something higher up the stack, or it could just be that your kernel was not build with additional wifi status messages enabled. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 3G multiple PDP context support
On Mon, 2011-01-10 at 18:49 -0800, Marcel Holtmann wrote: Hi Joe, If answered already sorry for the general question - searched archives and did not see much. I am wondering if there is support (on any 3G UMTS device) for simultaneous multiple-PDP contexts in NetworkManager. We have Qualcomm-based and other vendor commercial phones and dongles which support multiple-PDP context but no way to have active data over multiple contexts (3 simultaneous is desired). with off the shelf USB dongles, I have not seen this working properly actually. The only device I know of that can do this is MBM if you use the high-speed channel for one and PPP for the other one. Of course with cellphone modems like the ISI from Nokia or Infineon and even ST-Ericsson the multiple PDP context setup is possible. The biggest problem here is that if the dongles are bound to be using PPP, then normally no more than one PPP session is support. And thus only one active PDP context at a time. Main reason is that the resources inside the modem firmware is pretty much limited and PPP is a damn waste from resources point of view. If they are not using PPP, then normally they only give you one high speed Ethernet or point-to-point IP interface. That is not really enough to get you to the three you want. Also I don't really know if Modem Manager is designed for handling more than one PDP context per modem. It can, though we've been thinking about it in terms of concurrent IPv4 and IPv6 support like we can do for ethernet or wifi. Some operators do support IPv6 PDP contexts, and it would rock to have that working better. For devices that provide pseudo-ethernet-with-DHCP, perhaps it magically works with DHCP given the right PDP context type, but for most devices I doubt it. It's something that going forward I'm sure we'll see more of though, so it makes a lot of sense to play around with and work towards. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM disconnect after one hour with a wired network
Le 11/01/2011 16:13, Dan Williams a écrit : On Tue, 2011-01-11 at 12:53 +, Charles Cultien wrote: Le 11/01/2011 02:44, Dan Williams a écrit : On Mon, 2011-01-10 at 20:36 +, Charles Cultien wrote: Le 10/01/2011 16:35, Larry Finger a écrit : On 01/09/2011 05:15 AM, Charles Cultien wrote: Hi, I have a very strange problem : I'm connected with the wired network of my university and each time, after one hour, Network Manager disconnect himself and didn't reconnect automatically. So I have to reconnect by myself evry hour and this is boring ! I don't know why and how change this. A dmesg didn't show anything (on the moment it disconnect). I'm using LInux Mint DEbian (so debian testing) with : Linux kernel 2.6.32-5-686 GNOME 2.30.2 Network Manager 0.8.1 I'am am behind a proxy (automatically given by the script htpp://proxyconf) and so the gnome proxy is configured. Thank you for helping and didn't hesitate asking for trying something or given more information. Does the listing produced by running 'iw event -t -f' show anything at the time of disconnect? Larry I run this command : nothing appears before, during and after. When the disconnect happens, what does 'dmesg' report at the bottom of the output? Dan dmesg didn't show anything. The only thing showed before any cut (printed only one time) is this line : [ 1310.768042] CE: hpet increasing min_delta_ns to 15000 nsec This can't be coming from my connection because with Windows I haven't such a cut (or maybe the cut but it reconnect automatically). Can you grab /var/log/messages or /var/log/daemon.log when you note the disconnect and paste/attach the last 100 lines or so? It could be a DHCP failure too. If 'dmesg' doesn't say anything it could either be something higher up the stack, or it could just be that your kernel was not build with additional wifi status messages enabled. Dan You found something ineteresting! Something happened with DHCP (thanks to daemon.log) Here one complete cycle from one connection to the end (after I reconnect, etc) Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) starting connection 'Auto eth1' Jan 11 15:50:51 (none) NetworkManager[1618]: info (eth1): device state change: 3 - 4 (reason 0) Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled... Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 1 of 5 (Device Prepare) started... Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 2 of 5 (Device Configure) scheduled... Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 1 of 5 (Device Prepare) complete. Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 2 of 5 (Device Configure) starting... Jan 11 15:50:51 (none) NetworkManager[1618]: info (eth1): device state change: 4 - 5 (reason 0) Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 2 of 5 (Device Configure) successful. Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 3 of 5 (IP Configure Start) scheduled. Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 2 of 5 (Device Configure) complete. Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 3 of 5 (IP Configure Start) started... Jan 11 15:50:51 (none) NetworkManager[1618]: info (eth1): device state change: 5 - 7 (reason 0) Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Beginning DHCPv4 transaction (timeout in 45 seconds) Jan 11 15:50:51 (none) NetworkManager[1618]: info dhclient started with pid 9123 Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 3 of 5 (IP Configure Start) complete. Jan 11 15:50:51 (none) dhclient: Internet Systems Consortium DHCP Client 4.1.1-P1 Jan 11 15:50:51 (none) dhclient: Copyright 2004-2010 Internet Systems Consortium. Jan 11 15:50:51 (none) dhclient: All rights reserved. Jan 11 15:50:51 (none) dhclient: For info, please visit https://www.isc.org/software/dhcp/ Jan 11 15:50:51 (none) dhclient: Jan 11 15:50:51 (none) NetworkManager[1618]: info (eth1): DHCPv4 state changed nbi - preinit Jan 11 15:50:51 (none) dhclient: Listening on LPF/eth1/00:21:70:6f:42:3a Jan 11 15:50:51 (none) dhclient: Sending on LPF/eth1/00:21:70:6f:42:3a Jan 11 15:50:51 (none) dhclient: Sending on Socket/fallback Jan 11 15:50:54 (none) dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7 Jan 11 15:50:54 (none) dhclient: DHCPOFFER from 10.193.0.1 Jan 11 15:50:54 (none) dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Jan 11 15:50:54 (none) dhclient: DHCPACK from 10.193.0.1 Jan 11 15:50:54 (none) dhclient: bound to 10.193.247.250 -- renewal in 1544 seconds. Jan 11 15:50:54 (none) NetworkManager[1618]: info (eth1): DHCPv4 state changed preinit - bound Jan 11 15:50:54 (none) NetworkManager[1618]: info Activation (eth1) Stage 4 of 5 (IP4
Re: GSM modem via Bluetooth?
On Thu, Jan 6, 2011 at 10:16 PM, Dan Williams d...@redhat.com wrote: I spend some time on this over the holidays to figure out what it would take for manually started rfcomm ports to show up as Bluetooth modems and be configurable without the BT wizard. The short answer is that yes, this is possible, though it's somewhat icky. But even if NM exported the device as a Bluetooth modem, you'll still need connection details (APN, username, password) before you can ask NM to connect the device. That's correct; and as soon as connection was no more ignored by NM I was able to use knetworkmanager to configure it. So now I have fully functional connection definition. I'll look into further cleaning up the proof-of-concept patches I did and see if they can be merged in some form in the near future. Thank you! ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: GSM modem via Bluetooth?
On Thu, 2011-01-06 at 13:16 -0600, Dan Williams wrote: snip I spend some time on this over the holidays to figure out what it would take for manually started rfcomm ports to show up as Bluetooth modems and be configurable without the BT wizard. You'll still need to pair the device at some point anyway. The short answer is that yes, this is possible, though it's somewhat icky. But even if NM exported the device as a Bluetooth modem, you'll still need connection details (APN, username, password) before you can ask NM to connect the device. Exactly. I'll look into further cleaning up the proof-of-concept patches I did and see if they can be merged in some form in the near future. I think that this is probably best left alone until someone implements Bluetooth line discipline in pppd and the Linux kernel directly, so that reliance on rfcomm, or creation of serial ports through bluetoothd is unneeded. If you want to be able to use the /dev/rfcomm devices directly, I'd recommend making this hard to setup, so that people don't try and use it as the main way to create a connection to their device, rather as a debugging method (wrong Bluetooth port used for example). Creating an rfcomm device, making sure it stays across reboots, and making sure it points to the right port (which has absolutely no guarantees of staying the same across enabling/disabling the feature on the device), is a sure way to break things, and requires root access. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: GSM modem via Bluetooth?
On Tue, 2011-01-11 at 20:36 +0300, Andrey Borzenkov wrote: On Thu, Jan 6, 2011 at 10:16 PM, Dan Williams d...@redhat.com wrote: I spend some time on this over the holidays to figure out what it would take for manually started rfcomm ports to show up as Bluetooth modems and be configurable without the BT wizard. The short answer is that yes, this is possible, though it's somewhat icky. But even if NM exported the device as a Bluetooth modem, you'll still need connection details (APN, username, password) before you can ask NM to connect the device. That's correct; and as soon as connection was no more ignored by NM I was able to use knetworkmanager to configure it. So now I have fully functional connection definition. I'm guessing it would be easier to setup once NM takes care of creating connections in a way that doesn't require a particular backing store. So you'd set it up using the GNOME Bluetooth wizard, and have access to the same connection in KNetworkManager (or at least until the KDE Bluetooth bits gain the ability to do something similar). Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM disconnect after one hour with a wired network
On Tue, 2011-01-11 at 18:04 +, Charles Cultien wrote: Le 11/01/2011 16:13, Dan Williams a écrit : On Tue, 2011-01-11 at 12:53 +, Charles Cultien wrote: Le 11/01/2011 02:44, Dan Williams a écrit : On Mon, 2011-01-10 at 20:36 +, Charles Cultien wrote: Le 10/01/2011 16:35, Larry Finger a écrit : On 01/09/2011 05:15 AM, Charles Cultien wrote: Hi, I have a very strange problem : I'm connected with the wired network of my university and each time, after one hour, Network Manager disconnect himself and didn't reconnect automatically. So I have to reconnect by myself evry hour and this is boring ! I don't know why and how change this. A dmesg didn't show anything (on the moment it disconnect). I'm using LInux Mint DEbian (so debian testing) with : Linux kernel 2.6.32-5-686 GNOME 2.30.2 Network Manager 0.8.1 I'am am behind a proxy (automatically given by the script htpp://proxyconf) and so the gnome proxy is configured. Thank you for helping and didn't hesitate asking for trying something or given more information. Does the listing produced by running 'iw event -t -f' show anything at the time of disconnect? Larry I run this command : nothing appears before, during and after. When the disconnect happens, what does 'dmesg' report at the bottom of the output? Dan dmesg didn't show anything. The only thing showed before any cut (printed only one time) is this line : [ 1310.768042] CE: hpet increasing min_delta_ns to 15000 nsec This can't be coming from my connection because with Windows I haven't such a cut (or maybe the cut but it reconnect automatically). Can you grab /var/log/messages or /var/log/daemon.log when you note the disconnect and paste/attach the last 100 lines or so? It could be a DHCP failure too. If 'dmesg' doesn't say anything it could either be something higher up the stack, or it could just be that your kernel was not build with additional wifi status messages enabled. Dan You found something ineteresting! Something happened with DHCP (thanks to daemon.log) Here one complete cycle from one connection to the end (after I reconnect, etc) Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) starting connection 'Auto eth1' Jan 11 15:50:51 (none) NetworkManager[1618]: info (eth1): device state change: 3 - 4 (reason 0) Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 1 of 5 (Device Prepare) scheduled... Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 1 of 5 (Device Prepare) started... Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 2 of 5 (Device Configure) scheduled... Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 1 of 5 (Device Prepare) complete. Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 2 of 5 (Device Configure) starting... Jan 11 15:50:51 (none) NetworkManager[1618]: info (eth1): device state change: 4 - 5 (reason 0) Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 2 of 5 (Device Configure) successful. Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 3 of 5 (IP Configure Start) scheduled. Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 2 of 5 (Device Configure) complete. Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 3 of 5 (IP Configure Start) started... Jan 11 15:50:51 (none) NetworkManager[1618]: info (eth1): device state change: 5 - 7 (reason 0) Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Beginning DHCPv4 transaction (timeout in 45 seconds) Jan 11 15:50:51 (none) NetworkManager[1618]: info dhclient started with pid 9123 Jan 11 15:50:51 (none) NetworkManager[1618]: info Activation (eth1) Stage 3 of 5 (IP Configure Start) complete. Jan 11 15:50:51 (none) dhclient: Internet Systems Consortium DHCP Client 4.1.1-P1 Jan 11 15:50:51 (none) dhclient: Copyright 2004-2010 Internet Systems Consortium. Jan 11 15:50:51 (none) dhclient: All rights reserved. Jan 11 15:50:51 (none) dhclient: For info, please visit https://www.isc.org/software/dhcp/ Jan 11 15:50:51 (none) dhclient: Jan 11 15:50:51 (none) NetworkManager[1618]: info (eth1): DHCPv4 state changed nbi - preinit Jan 11 15:50:51 (none) dhclient: Listening on LPF/eth1/00:21:70:6f:42:3a Jan 11 15:50:51 (none) dhclient: Sending on LPF/eth1/00:21:70:6f:42:3a Jan 11 15:50:51 (none) dhclient: Sending on Socket/fallback Jan 11 15:50:54 (none) dhclient: DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 7 Jan 11 15:50:54 (none) dhclient: DHCPOFFER from 10.193.0.1 Jan 11 15:50:54 (none) dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67 Jan 11 15:50:54 (none) dhclient: DHCPACK from 10.193.0.1 Jan 11 15:50:54 (none) dhclient: bound to 10.193.247.250 -- renewal in 1544
Re: GSM modem via Bluetooth?
On Tue, 2011-01-11 at 17:49 +, Bastien Nocera wrote: On Thu, 2011-01-06 at 13:16 -0600, Dan Williams wrote: snip I spend some time on this over the holidays to figure out what it would take for manually started rfcomm ports to show up as Bluetooth modems and be configurable without the BT wizard. You'll still need to pair the device at some point anyway. The short answer is that yes, this is possible, though it's somewhat icky. But even if NM exported the device as a Bluetooth modem, you'll still need connection details (APN, username, password) before you can ask NM to connect the device. Exactly. I'll look into further cleaning up the proof-of-concept patches I did and see if they can be merged in some form in the near future. I think that this is probably best left alone until someone implements Bluetooth line discipline in pppd and the Linux kernel directly, so that reliance on rfcomm, or creation of serial ports through bluetoothd is unneeded. If you want to be able to use the /dev/rfcomm devices directly, I'd recommend making this hard to setup, so that people don't try and use it as the main way to create a connection to their device, rather as a debugging method (wrong Bluetooth port used for example). Creating an rfcomm device, making sure it stays across reboots, and making sure it points to the right port (which has absolutely no guarantees of staying the same across enabling/disabling the feature on the device), is a sure way to break things, and requires root access. It's more for KDE, which doesn't have a bluetooth wizard that does the same thing as the Gnome applet. Ideally, KDE should get that functionality, but making already-paired-but-unconfigured devices show up as NM bluetooth devices would let the kde bits at least configure the device. I don't think it's very useful to have a raw rfcomm port show up as non-bluetooth device though (ie, a USB 3G stick) because then you have to start up the rfcomm port every single time manually. That sucks, and the real fix there is to either (1) get a bluetooth wizard if you don't have one, or (2) modify the applet you're using to be able to create new BT DUN configs if NM presents the device. The patches I did would do #2, which could also be useful in Gnome if you didn't check the boxes at the end of pairing for some reason. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: how to turn off automatic switch from wifi to cable?
On Tue, 2011-01-04 at 09:46 -0600, Radoslaw Garbacz wrote: Hi, I would like to use my machine as a router. My wifi is connected to the Internet, and my ethernet I would like to use for a local network. For now any time I plug-in the cable NetworkManager disconnects wifi. Is there a way to make it more flexible, to configure it, or to disable the automatic switch? NM 0.7 or later will keep both up at the same time. What you probably want to do is mark your Ethernet connection as Only use this connection for resources on its network in the IPv4 Routes dialog of the connection editor, which will make sure the ethernet device never gets the default route. When you do that, the wifi device will still have the default route, and will still be used for the Internet. dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Help with wireless device
On Fri, 2010-12-31 at 15:00 -0600, Larry Finger wrote: Hi, One of the people I'm trying to help on the openSUSE Forum has a problem in that the KDE applet always has wireless networking disabled. Once it is enabled manually, then the wireless comes up as expected. In /var/log/NetworkManager, the following is reported: Dec 31 14:54:59 linux-ioxs NetworkManager: info (wlan0): bringing up device. Dec 31 14:54:59 linux-ioxs NetworkManager: info (wlan0): deactivating device (reason: 2). Dec 31 14:54:59 linux-ioxs NetworkManager: info modem-manager is now available Dec 31 14:54:59 linux-ioxs NetworkManager: WARN default_adapter_cb(): bluez error getting default adapter: The name org.bluez was not provided by any .service files Dec 31 14:54:59 linux-ioxs NetworkManager: info Trying to start the supplicant... Dec 31 14:54:59 linux-ioxs NetworkManager: info (wlan0): supplicant manager state: down - idle Dec 31 14:54:59 linux-ioxs nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/netcontrol_services' exited with error status 127. Why is wlan0 deactivated with reason 2? When NM starts up, it will take over devices and in most cases (except for wired) will deactivate them to bring them back to a clean state. For anything other than wired, there's a crap-ton of state that NM would need to read and acquire if it just took over the existing wifi connection or whatever. That includes supplicant state, possibly a dhclient instance, maybe even PPPoE. Most of these things don't export a dbus interface, and thus it's even harder to get that state on startup and seamlessly take over the interface. Second, NM usually gets started at boot time, so it's not really an issue, and people don't usually restart NM while the system is up. So this is normal on NM start. What you're probably wondering is why nothing gets connected *after* this point. Which Jiri posted some questions about... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Correctly write resolv.conf when using OpenVPN plugin
On Sat, 2010-12-25 at 00:27 +0300, Pentarh Udi wrote: I decided to use OpenVPN plugin of NetworkManager instead of of openvn CLI binary and I begin to expect name resolving problems. Original bug was posted in https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/651007 People there suggested to write to this mailing list, so... Problem is in very slow name resolution when connecting to OpenVPN peer and obtaining DNS servers from there by directive push dhcp-option DNS x.x.x.x While investigating this issue I found that NM append obtained DNS servers to existing resolv.conf. So libc uses not only DNS servers from OpenVPN peer, but original DNS servers too. It should be noticed that original DNS servers WILL LIKELY be unreacable after establishing VPN connection. In my case resolv.conf BEFORE openvpn connection is: - nameserver 212.48.193.37 nameserver 192.168.100.1 - And after is: - # Generated by NetworkManager nameserver 88.85.66.222 nameserver 78.140.128.205 nameserver 213.158.7.2 # NOTE: the libc resolver may not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver 212.48.193.37 nameserver 192.168.100.1 In this case last three servers are invalid as they are not reachable after VPN connection, so name resolve becomes totally slow after openvpn connection because libc tries to get DNS answer from all servers: -- r...@pentarh-netbook:/var/log# tcpdump -i tun0 -n port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes 22:33:46.803557 IP 10.20.10.6.55426 213.158.7.2.53: 32890+ A? mail.google.com. (33) 22:33:51.807076 IP 10.20.10.6.58861 212.48.193.37.53: 32890+ A? mail.google.com. (33) 22:33:55.521957 IP 10.20.10.6.60601 213.158.7.2.53: 49670+ A? www.google.com. (32) 22:34:00.527135 IP 10.20.10.6.57982 212.48.193.37.53: 49670+ A? www.google.com. (32) 22:34:09.760264 IP 10.20.10.6.39286 88.85.66.222.53: 27804+ A? pagead2.googleadservices.com. (46) 22:34:09.946468 IP 88.85.66.222.53 10.20.10.6.39286: 27804 5/4/4 CNAME pagead.l.google.com., A 209.85.149.167, A 209.85.149.164, A 209.85.149.165, A 209.85.149.166 (276) 22:34:11.505444 IP 10.20.10.6.45653 213.158.7.2.53: 41142+ A? chatenabled.mail.google.com. (45) -- As you can see, libc tries to resolve mail.google.com from old unreachable servers and gets the answer from correct DNS after 20 seconds (!!!) of first query. This should be fixed, it makes OpenVPN plugin for NM unusable. The workaround of this issue may be providing static routes to original DNS IP, but i cant do that in NM openvpn plugin configuration, this option is inactive. As you pointed out, it depends on routing whether the original servers are available or not. And if you check the Only use this connection for resources on its network then any non-VPN traffic will still go over the wifi or ethernet or 3G device, not over the VPN, and likely the original DNS servers will be used. However, libc queries the DNS servers *in order listed*, so it's odd that anything would be trying to query the older servers at all. Note that libc does *not* refresh DNS information when resolv.conf changes, so if an application does not call res_init() before it makes DNS lookups, it may be using old information. This is a well-known glibc design choice that upstream glibc has declined to change. THe solution is to run a local caching nameserver that supports split DNS, thus any queries for VPN-specific nameservers can go to the VPN, and everythign else can go to your normal nameservers. So in the end, there are some things NM could do here. If the original nameservers are on subnets that are now owned by the VPN, NM probably shouldn't put those in resolv.conf. But on the other hand, it's a bug in applications to be using old DNS information, which is only fixed in the application by using res_init(), or by using a local caching nameserver. NM 0.8.2 and later has native support for dnsmasq as a local caching nameserver. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM and pm-utils sleep hook
On Sat, 2010-12-18 at 10:01 -0600, Robby Workman wrote: Hi Dan, Re this commit: commit 8310593ce48a85aa82d4a2adf805662f2b019ef5 Author: Dan Williams d...@redhat.com Date: Fri Oct 15 10:28:38 2010 -0500 core: ignore authorization for sleep/wake requests (but restrict to root) (rh #638640) Everyone uses pm-utils still for sleep/wake support, and that's traditionally how NM was put to sleep and woken up. But pm-utils uses dbus-send without --print-reply so dbus-send quits immediately after sending the message. That doesn't give NM enough time to get the senders UID and thus validate the request, so the request gets denied, and sometimes NM stays asleep after the machine is woken up. Instead, don't get the sender's UID and try to authorize it, but just let the request go through. Rely on D-Bus permissions to make sure that only root can call sleep/wake methods. Why not have NM ship the pm-utils sleep hook instead of having to work around what they ship? Last I checked, NM is the only app for which upstream pm-utils ships a sleep hook, and Victor (the lead dev there) was hoping to have apps ship their own so that he didn't have to maintain stuff that he may not be familiar with. I'm happy to ship the hooks in NM. I've talked about doing that for a couple years already, it's just never happened :) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fwd: NetworkManager connection priority - same ssid ?
2011/1/10 mike cloaked mike.cloa...@gmail.com On Mon, Jan 10, 2011 at 4:19 PM, Franco Miceli fmic...@plan.ceibal.edu.uy wrote: Mike, I have been dealing with the AP algorithm selection a few months ago. The one that selects the best connection is NM. If you get the src you can see it in the file nm-device-wifi.c (for the wireless connections). The way it is implemented in nm 0.7 (which is the one I have been working on) is that NM will go through each favourite connection you have, and comparing them with the ones available from scan results. It does not prioritize on signal strength rather than timestamp. Which means if the one you last connected to is available it will connect to that one. I have been playing with the code in order to make that selection signal sensitive. In order to do that you need to get signal strength info. The method nm_ap_get_strength(ap) can help get such data. The thing is that not all wireless adapters report well signal strength, but if you trust yours, then you can make this mod. Hope I could help. If you need I can share the code I used. Thanks Franco - I need to understand a few things - The version that is current in F14 that I am running is NetworkManager-0.8.1-10.git20100831.fc14.i686 and, as José Queiroz mentions in his subsequent reply, there have been many important changes since v7, although he does not reference a link to what those changes have been in v0.8. However, what I do not know is whether the selection of AP was made signal sensitive in the implemented changes in 0.8 or not? Certainly the last signal used appears to be the one selected when booting up the machine after switching off previously, which would be a reasonable first option for the starting choice, but then a secondary criterion where a stronger signal that already has been used, and is listed in the connections in NM, would be selected and switched in instead. Having such a two-stage selection would be what would suit me (and many others) better than just going to the last one used. I wonder if José Queiroz would tell us if this is in fact what has been implemented in 0.8 (or 0.81 or 0.82) or not? That would be very helpful. If this has been put into the code but has residual bugs then presumably getting some data and putting in a bug report so that developers could look at fixing it would be the way forward? A nice level headed and fact based approach to this would be ideal. I could swear that this was already discussed here, but the only reference I found was another message of mine. In the lack of good references, I ran to my kubuntu box. I also have an ESS in my home. My syslog shows several messages from wpa_supplicant about group rekeyings to one of the APs (the one that haves the strongest signal in the place I usually use my notebook). In one moment, I see messages from the kernel about deauthenticating the first AP, and authenticating the second one. Around these messages, I see only messages from wpa_supplicant, even though NM debugging is enabled. So I concluded that this reassociation was ordered by wpa_supplicant, not by NM. But, I admit, this is only an empirical verification; I didn't checked any code to confirm this. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] one more +CREG syntax
On Tue, 2010-12-21 at 21:18 +0100, Michał Sroczyński wrote: Hi, With current version of modem-manager connecting to the internet using Samsung Wave S8500 doesn't work (I've used modemmanager from fedora-14: 0.4-4.git20100720). It turned out that samsung's response for +CREG is different than expected (it has extra parameter). So I've added another (7th) syntax to mm_gsm_creg_regex_get. Now it works ok with the attached patch. It would be nice if it got included next version of modem-manager. Probably Wave isn't the only phone with such a syntax. Pushed, thanks. The 'B' there isn't very useful, and while that's probably some sort of access technology marker, I have no idea what it means and cannot find anything about it. Does it change? Can you lock the phone into 2G mode and see what it says, then lock it into 3G mode and report what it changes to, if anything? In any case, fix pushed as: f4d4569cdd4441ea210297cf1ed14b8e7e77fd34 Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Verizon Cellular service and NetworkManager shared networking
On Sat, 2010-12-18 at 15:58 -0500, Andy Graybeal wrote: Hi everyone, I've purchased the Verizon Cellular internet service for home. I love it, especially when compared to regular dial-up, which is what I'm used to. I have the USB760 and I got this to work just perfect after I followed the second post on this forum thread: http://ubuntuforums.org/showthread.php?t=1002262 One problem that I have is when I share the internet (USB760 = ppp0) over ethernet (eth0) with NetworkManager.. Verizon will disconnect... say every 20 minutes or so; sometimes 5 seconds, sometimes 45 minutes, but mostly around 20 minutes. The service is disconnected by this: LCP terminated by peer a command sent from Verizon after what I've suspect (and from what I've read in the forums) they've received too many(?) private ip addresses sent to their public network. (here's the post confirming this: http://www.mail-archive.com/networkmanager-list@gnome.org/msg10840.html ) Here's a post with what might be the answer: http://www.mail-archive.com/networkmanager-list@gnome.org/msg14760.html The poster outlines changing: iptables -A FORWARD -i eth0 -o ppp0 -j ACCEPT to this: iptables -A FORWARD -i eth0 -o ppp0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT iptables -A FORWARD -j drop-and-log-it But how do I configure NetworkManager's iptable settings to get this to work? Is it in the NetworkManager's script files (none of which I understand)? I don't understand iptables either. I'm a little better at pf. Any help is appreciated. I posted this to the ubuntu users list, but I didn't receive any responses. One thing you can do, for the time being, is make a 'dispatcher' script that does this. It's a small script that gets called whenever things happen with the network, and in your case that's a great place to put this. The script gets called with the interface name that came up or down, so you can just pop this command into a small script in /etc/NetworkManager/dispatcher.d, and match against the interface name starting with ppp. Note you'll want the IP_IFACE environment variable from the script, not the actual interface name passed as a command-line parameter to the script as $1. Note that it won't *always* be ppp0. There's various information out there on creating dispatcher scripts, and there may even be some already installed on your system. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Slackware init script fixes
On Wed, 2010-12-22 at 09:14 -0600, Robby Workman wrote: Attached are two patches for the Slackware init script 0001: Remove HAL requirement in rc.networkmanger 0002: Add a sleep 2 in the restart() function Both pushed, thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 3G multiple PDP context support
Hi Dan, If answered already sorry for the general question - searched archives and did not see much. I am wondering if there is support (on any 3G UMTS device) for simultaneous multiple-PDP contexts in NetworkManager. We have Qualcomm-based and other vendor commercial phones and dongles which support multiple-PDP context but no way to have active data over multiple contexts (3 simultaneous is desired). with off the shelf USB dongles, I have not seen this working properly actually. The only device I know of that can do this is MBM if you use the high-speed channel for one and PPP for the other one. Of course with cellphone modems like the ISI from Nokia or Infineon and even ST-Ericsson the multiple PDP context setup is possible. The biggest problem here is that if the dongles are bound to be using PPP, then normally no more than one PPP session is support. And thus only one active PDP context at a time. Main reason is that the resources inside the modem firmware is pretty much limited and PPP is a damn waste from resources point of view. If they are not using PPP, then normally they only give you one high speed Ethernet or point-to-point IP interface. That is not really enough to get you to the three you want. Also I don't really know if Modem Manager is designed for handling more than one PDP context per modem. It can, though we've been thinking about it in terms of concurrent IPv4 and IPv6 support like we can do for ethernet or wifi. Some operators do support IPv6 PDP contexts, and it would rock to have that working better. For devices that provide pseudo-ethernet-with-DHCP, perhaps it magically works with DHCP given the right PDP context type, but for most devices I doubt it. It's something that going forward I'm sure we'll see more of though, so it makes a lot of sense to play around with and work towards. there will be eventually a IPV4V6 context type coming as well that properly represents a dual-stack from network point of view. Some vendors do that magically for you if you don't have that one and you have to do IP and IPV6 context separately. So the host will see it as just one Ethernet or IP interface. In case we have two separate context in the host, I am currently toying with the idea of just smashing them together via TUN/TAP device or inside the kernel directly. But this is all just an idea right now. On the other hand, the number of dongles that support IPv6 right now and the number of networks providing this to end customers is limited. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Fwd: NetworkManager connection priority - same ssid ?
2011/1/11 José Queiroz zekk...@gmail.com: I could swear that this was already discussed here, but the only reference I found was another message of mine. In the lack of good references, I ran to my kubuntu box. I also have an ESS in my home. My syslog shows several messages from wpa_supplicant about group rekeyings to one of the APs (the one that haves the strongest signal in the place I usually use my notebook). In one moment, I see messages from the kernel about deauthenticating the first AP, and authenticating the second one. Around these messages, I see only messages from wpa_supplicant, even though NM debugging is enabled. So I concluded that this reassociation was ordered by wpa_supplicant, not by NM. But, I admit, this is only an empirical verification; I didn't checked any code to confirm this. Thanks - I will try and run some tests next weekend - and see if I can get any useful log data and I will use a different machine to the one I used in the original tests (both running f14 but with different wireless hardware) - it would be nice to get to the bottom of this. Mike -- mike c ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Fwd: Re: Verizon Cellular service and NetworkManager shared networking
Original Message Subject: Re: Verizon Cellular service and NetworkManager shared networking Date: Tue, 11 Jan 2011 15:59:57 -0500 From: Andy Graybeal andy.grayb...@casanueva.com To: Dan Williams d...@redhat.com One thing you can do, for the time being, is make a 'dispatcher' script that does this. It's a small script that gets called whenever things happen with the network, and in your case that's a great place to put this. The script gets called with the interface name that came up or down, so you can just pop this command into a small script in /etc/NetworkManager/dispatcher.d, and match against the interface name starting with ppp. Note you'll want the IP_IFACE environment variable from the script, not the actual interface name passed as a command-line parameter to the script as $1. Note that it won't *always* be ppp0. There's various information out there on creating dispatcher scripts, and there may even be some already installed on your system. Dan Dan, thank you for the response. I'll be reading more about what you wrote and trying this out. I'll respond with how it works out. Thanks again, I had kinda given up on this and installed MS Windows shamefully. -Andy ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
