Re: howto disable default multiple device activation?
On Tue, Nov 25, 2008 at 6:42 PM, Nikolaus Filus [EMAIL PROTECTED] wrote: Tony Espy wrote: What about 3g? Does it also stay connected when an Ethernet cable is plugged in? If so, couldn't that have financial implications to the end-user? Yes, 3g is handled the same way. Modems are different though, they are not activated automatically, so if you remember to activate it when you need it, you should remember to deactivate it as well. Plus, (AFAIK) there's no financial implications when you have the modem activated but not used for any traffic, so in case of active 3g device and ethernet device, all the traffic goes through ethernet device (unless it's specifically to the IP network of your modem). I'm responsible for a little office network and I never saw a use case for connection sharing in office environments. This is also one of those things I disallow for all users. In my eyes only some end users need this for their home networks in rare cases. If you so strongly feel it's bad, then it's your responsibility to pre-configure your office laptops (machines with wifi devices) to have a connection profile for your local wifi network with property connect automatically not set. Besides that I always hated the default windows behaviour of acquiring IP adresses on all interfaces, what means everyone gets 1 ethernet and 1 wireless address. I don't want to have this on linux. Do you have any reasons to hate it, other than I have a gut feeling that this is bad? The fastest device is always used for new TCP connections, so it's not like it'll slow anything down. Here's a specific example why it's good: I'm connected through my wifi device only and have a bunch of open TCP connections (ssh, irc, ...). Then I need to transfer a large file from the local network. I plug in the cable (to make it faster) and start the transfer. When it's done (or whenever I feel like it), I unplug the cable. With 0.6 behavior, I'd need to start my processes 3 times. My point is, there's simply no reason to deactivate the previously active device, it's used until it's necessary and then just stays there until it's needed again. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Powersaving Patch for NetworkManager
Hi Dan,
I added a simple wrapper for g_timeout_add_seconds.
Jan Kantert
Dan Williams schrieb:
On Tue, 2008-11-25 at 13:38 +0100, Jan Kantert wrote:
Hi,
according to powertop Network Manager wakes up my cpu about once every
two seconds. Thats does not sound much but on an idle desktop with 10
wake ups per seconds thats 5%. I wanted my laptop's cpu to stay longer
in sleepstates so I wrote a little patch (against trunk) to replace
g_timeout_add with g_timeout_add_seconds (where possible), which uses
more rough granularity. This helps to aggregate timeouts and will
statistically wake up the cpu less frequently.
Good thing to do, but you'll need to check the glib version being used,
and if it's not = 2.14, re-implement g_timeout_add_seconds() in
NetworkManagerUtils.c, which should simply call g_timeout_add or
whatever. Care to respin?
Thanks!
Dan
Greetings,
Jan Kantert
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Index: vpn-daemons/pptp/src/nm-pptp-service.c
===
--- vpn-daemons/pptp/src/nm-pptp-service.c (Revision 4333)
+++ vpn-daemons/pptp/src/nm-pptp-service.c (Arbeitskopie)
@@ -364,7 +364,7 @@
#define NM_PPTP_PLUGIN_GET_PRIVATE(o) (G_TYPE_INSTANCE_GET_PRIVATE ((o), NM_TYPE_PPTP_PLUGIN, NMPptpPluginPrivate))
#define NM_PPTP_PPPD_PLUGIN PLUGINDIR /nm-pptp-pppd-plugin.so
-#define NM_PPTP_WAIT_PPPD 1 /* 10 seconds */
+#define NM_PPTP_WAIT_PPPD 10 /* 10 seconds */
#define PPTP_SERVICE_SECRET_TRIES pptp-service-secret-tries
typedef struct {
@@ -870,7 +870,7 @@
NM_PPTP_PLUGIN_GET_PRIVATE (plugin)-pid = pid;
g_child_watch_add (pid, pppd_watch_cb, plugin);
- priv-ppp_timeout_handler = g_timeout_add (NM_PPTP_WAIT_PPPD, pppd_timed_out, plugin);
+ priv-ppp_timeout_handler = g_timeout_add_seconds (NM_PPTP_WAIT_PPPD, pppd_timed_out, plugin);
return TRUE;
}
@@ -1088,7 +1088,7 @@
if (priv-pid) {
if (kill (priv-pid, SIGTERM) == 0)
- g_timeout_add (2000, ensure_killed, GINT_TO_POINTER (priv-pid));
+ g_timeout_add_seconds (2, ensure_killed, GINT_TO_POINTER (priv-pid));
else
kill (priv-pid, SIGKILL);
Index: vpn-daemons/openvpn/src/nm-openvpn-service.c
===
--- vpn-daemons/openvpn/src/nm-openvpn-service.c (Revision 4333)
+++ vpn-daemons/openvpn/src/nm-openvpn-service.c (Arbeitskopie)
@@ -975,7 +975,7 @@
if (priv-pid) {
if (kill (priv-pid, SIGTERM) == 0)
- g_timeout_add (2000, ensure_killed, GINT_TO_POINTER (priv-pid));
+ g_timeout_add_seconds (2, ensure_killed, GINT_TO_POINTER (priv-pid));
else
kill (priv-pid, SIGKILL);
Index: vpn-daemons/vpnc/src/nm-vpnc-service.c
===
--- vpn-daemons/vpnc/src/nm-vpnc-service.c (Revision 4333)
+++ vpn-daemons/vpnc/src/nm-vpnc-service.c (Arbeitskopie)
@@ -524,7 +524,7 @@
if (priv-pid) {
if (kill (priv-pid, SIGTERM) == 0)
- g_timeout_add (2000, ensure_killed, GINT_TO_POINTER (priv-pid));
+ g_timeout_add_seconds (2, ensure_killed, GINT_TO_POINTER (priv-pid));
else
kill (priv-pid, SIGKILL);
Index: src/dhcp-manager/nm-dhcp-manager.c
===
--- src/dhcp-manager/nm-dhcp-manager.c (Revision 4333)
+++ src/dhcp-manager/nm-dhcp-manager.c (Arbeitskopie)
@@ -602,7 +602,7 @@
timeout = NM_DHCP_TIMEOUT;
/* Set up a timeout on the transaction to kill it after the timeout */
- device-timeout_id = g_timeout_add (timeout * 1000,
+ device-timeout_id = g_timeout_add_seconds (timeout,
nm_dhcp_manager_handle_timeout,
device);
Index: src/NetworkManagerUtils.c
===
--- src/NetworkManagerUtils.c (Revision 4333)
+++ src/NetworkManagerUtils.c (Arbeitskopie)
@@ -504,3 +504,14 @@
g_object_unref (dbus_mgr);
}
+#if !GLIB_CHECK_VERSION(2,14,0)
+static inline guint
+g_timeout_add_seconds (guint interval,
+ GSourceFunc function,
+ gpointer data)
+{
+g_return_val_if_fail (function != NULL, 0);
+
+return g_timeout_add_full (G_PRIORITY_DEFAULT, interval * 1000, function, data, NULL);
+}
+#endif /* !GLIB_CHECK_VERSION(2,14,0) */
Index: src/nm-device-ethernet.c
===
--- src/nm-device-ethernet.c (Revision 4333)
+++ src/nm-device-ethernet.c (Arbeitskopie)
@@ -991,7 +991,7 @@
/* Start the link timeout so we allow some time for reauthentication */
if (!priv-link_timeout_id)
-priv-link_timeout_id = g_timeout_add (15000, link_timeout_cb, dev);
+priv-link_timeout_id = g_timeout_add_seconds (15, link_timeout_cb, dev);
}
}
@@ -1156,7 +1156,7 @@
self);
Re: Powersaving Patch for NetworkManager
On Tue, Nov 25, 2008 at 01:38:12PM +0100, Jan Kantert wrote: Hi, according to powertop Network Manager wakes up my cpu about once every two seconds. Thats does not sound much but on an idle desktop with 10 wake ups per seconds thats 5%. I wanted my laptop's cpu to stay longer in sleepstates so I wrote a little patch (against trunk) to replace g_timeout_add with g_timeout_add_seconds (where possible), which uses more rough granularity. This helps to aggregate timeouts and will statistically wake up the cpu less frequently. Sounds good. Curious, if you have collected data on how much of a powersaving win this patch brings? - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Powersaving Patch for NetworkManager
On Wed, Nov 26, 2008 at 1:59 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 25, 2008 at 01:38:12PM +0100, Jan Kantert wrote: Hi, according to powertop Network Manager wakes up my cpu about once every two seconds. Thats does not sound much but on an idle desktop with 10 wake ups per seconds thats 5%. I wanted my laptop's cpu to stay longer in sleepstates so I wrote a little patch (against trunk) to replace g_timeout_add with g_timeout_add_seconds (where possible), which uses more rough granularity. This helps to aggregate timeouts and will statistically wake up the cpu less frequently. Sounds good. Curious, if you have collected data on how much of a powersaving win this patch brings? The patch itself won't save much power, but when other apps wake up less often too the cpu will spend more time idle and therefore save power. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
AW: Re: howto disable default multiple device activation?
Do you have any reasons to hate it, I for instance would - although much less on a unixoid OS than on *eew* Windoze. With multiple IP interfaces, there is a strong tendency for nonunicast IP packets leaving the box via the wrong interface - regardless of the source address being written into the packet. So in general, I would see use cases for not automatically having a wired and a wireless interfaces active at the same time. Some Laptop firmwares even have such a Wifi XOR LAN switch you can activate in their BIOSs. The fastest device is always used for new TCP connections, so it's not like it'll slow anything down. How does TCP know about an interface's speed? I would assume that it just passes it's segments to the IP layer - which will then forward packets according to what the routing table says. Here's a specific example why it's good: I'm connected through my wifi device only and have a bunch of open TCP connections (ssh, irc, ...). Then I need to transfer a large file from the local network. I plug in the cable (to make it faster) and start the transfer. The way you describe it, it sounds like a small setup witha single router/firewall towards the internet, with some (file) server on your internal LAN. So both your WiFi and LAN NICs will probably have addresses from the same subnet and use the same router/firewall to reach non-local networks. As soon as your LAN NIC is up, the routing table gets modified to reach the local LAN via that interface and maybe another default route, pointing to the same router/firewall. Like this, TCP connections to the outside world will survive and not seem out-of-state to that firewall. But what happens to your routing table once you get DHCP lease and default route from a completely different LAN? Will the new default route take precedence over the existing one? How do you prevent problems if your now dual-homed hosts needs to talk to hosts beyond the respective local subnet - on both interfaces simultaneously? My point is, there's simply no reason to deactivate the previously active device, Yes. There are use cases where this is mandatory. As you pointed out - this needs to be taken care of by the administrator. regards Marc ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
0.7 connecting to hidden network
I've been tinkering with nm-applet 0.7 and seeing if I can get it to connect easily to my hidden, encrypted wireless network when I resume from suspend-to-RAM. It's almost where I think it should be, but still a little buggy. Here's what I do to connect now: 1. Left mouse click on applet 2. Select Connect to Hidden Wireless Network... 3. In the pop-up that appears, select my local network from a list 4. Click the Connect button on that popup (it remembers correctly my ESSID and encryption key from connecting successfully before). 5. Wait for it to time out (this takes 25 seconds according to syslog) 6. Cancel the prompt asking me to re-enter the encryption key 7. Left mouse click on nm-applet again 8. Select my local network directly from a radio button (now it is in the list) 9. It now connects promptly What's odd to me is why it's not connecting immediately after step 4, but it times out. At first I suspected it may not have the right encryption key at that point, but if I run iwconfig as root while waiting for it to time out, I see my encryption key correctly. I compared that output to what I get when running iwconfig once I'm connected, and the differences are tiny: diff --unified=0 conf conf2 --- conf2008-11-25 20:28:43.0 -0500 +++ conf2 2008-11-25 20:29:49.0 -0500 @@ -2,2 +2,2 @@ - Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated - Tx-Power=27 dBm + Mode:Managed Frequency:2.412 GHz Access Point: 00:16:01:93:6A:73 + Bit Rate=36 Mb/s Tx-Power=27 dBm @@ -7 +7 @@ - Link Quality:0 Signal level:0 Noise level:0 + Link Quality=79/100 Signal level=-55 dBm Noise level=-90 dBm When I'm connected, I see the MAC address of my access point instead of Not-Associated; I see the bit rate; and the link quality, signal level, and noise level outputs all have nonzero values. So it looks like I *am* setting the right encryption key on the first connection attempt, but for some reason it's still not connecting. I think there is some other initialization that happens when selecting the network via the radio button which isn't happening when I select it via the list of hidden networks: if at step 6 above I instead click on the connect button again from the popup window, the connection times out as before. It only connects if I cancel that window and then explicitly select the network via radio button from the list of visible wireless networks. But if I try to reconnect (while I'm still connected) by selecting from the hidden wireless networks popup, then it will connect again. So to recap, by selecting my network from the hidden wireless networks list, I can't get it to connect after resume, but I do get my network to appear in the list of visible networks. And once I pick it from that list, I'm able to connect as I'd expect. This is an improvement over 0.6x - in that version, I needed to manually retype my encryption key, and now I don't have to do so. But it's still more cumbersome than it should be: I should connect once I've selected from the hidden networks list. I'd be happy to help test a patch to address this. I'm currently running the 0.7 Ubuntu backports Alexander Sack suggested here: http://mail.gnome.org/archives/networkmanager-list/2008-November/msg00202.html Now if I try to build nm-applet from a clean SVN checkout (I'm currently at revision 1047), the compilation fails: utils.c: In function ‘fill_one_private_key’: utils.c:245: error: ‘NMSetting8021xCKType’ undeclared (first use in this function) utils.c:245: error: (Each undeclared identifier is reported only once utils.c:245: error: for each function it appears in.) utils.c:245: error: expected ‘;’ before ‘pk_type’ cc1: warnings being treated as errors utils.c:246: warning: ISO C90 forbids mixed declarations and code utils.c:254: warning: implicit declaration of function ‘nm_setting_802_1x_set_private_key_from_file’ utils.c:254: error: ‘pk_type’ undeclared (first use in this function) utils.c:255: error: ‘NM_SETTING_802_1X_CK_TYPE_PKCS12’ undeclared (first use in this function) Regards, Geoff Buchan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Re: howto disable default multiple device activation?
On Wed, Nov 26, 2008 at 02:06:23PM +, [EMAIL PROTECTED] wrote: Do you have any reasons to hate it, I for instance would - although much less on a unixoid OS than on *eew* Windoze. With multiple IP interfaces, there is a strong tendency for nonunicast IP packets leaving the box via the wrong interface - regardless of the source address being written into the packet. So in general, I would see use cases for not automatically having a wired and a wireless interfaces active at the same time. Some Laptop firmwares even have such a Wifi XOR LAN switch you can activate in their BIOSs. The fastest device is always used for new TCP connections, so it's not like it'll slow anything down. How does TCP know about an interface's speed? I would assume that it just passes it's segments to the IP layer - which will then forward packets according to what the routing table says. NM tweaks the routing table in such a way that traffic is going through faster devices. So TCP doesnt know; instead NM guesses what is a the best interface. - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: 0.7 connecting to hidden network
On Wed, Nov 26, 2008 at 07:38:51AM -0500, Geoff Buchan wrote: So to recap, by selecting my network from the hidden wireless networks list, I can't get it to connect after resume, but I do get my network to appear in the list of visible networks. And once I pick it from that list, I'm able to connect as I'd expect. I'd be happy to help test a patch to address this. I'm currently running the 0.7 Ubuntu backports Alexander Sack suggested here: http://mail.gnome.org/archives/networkmanager-list/2008-November/msg00202.html What driver are you using? If its iwl try to install the linux-backport-modules package. - Alexander ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Automatically connect to vpn
When at the University I need to use VPN to get internet access. When I am at home or at other locations I need to use VPN for access to email and scientific journals, so I use a different VPN profile for this. I have seen that NetworkManager can run a script when there is a change in network status. Is there any way I can have NetworkManager automatically connect to a specific VPN profile depending on which network I am connected to, and get the normal visual feedback from nm-applet about the VPN connection? I sometimes lose the VPN connection, so it's nice to get a notification of this. Harald ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Automatically connect to vpn
On Wed, 2008-11-26 at 14:11 +0100, Harald Solheim wrote: When at the University I need to use VPN to get internet access. When I am at home or at other locations I need to use VPN for access to email and scientific journals, so I use a different VPN profile for this. I have seen that NetworkManager can run a script when there is a change in network status. Is there any way I can have NetworkManager automatically connect to a specific VPN profile depending on which network I am connected to, and get the normal visual feedback from nm-applet about the VPN connection? I sometimes lose the VPN connection, so it's nice to get a notification of this. This functionality is planned. However, you might be able to get it implemented by using a dispatcher script based on the connection UUID that was just activated. Have a list of connection UUIDs that you'd like the VPN to activate for, and when that connection is brought up, ask NM to activate that VPN. However, this will only work for system-wide connections, because the scripts are run as root. Hence why it's better to get it fully integrated into NM itself. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Still VPN routing problems
I posted a while back about routing problems when using a VPN over mobile broadband. I've just been trying the most recent builds on launchpad (two of them), and the routing setup has changed, but it's still not quite right. Both builds do the same thing - here are the routes for the PPP connection, and then PPTP over PPP. PPP only: Destination Gateway Genmask Flags Metric RefUse Iface 10.37.79.0 0.0.0.0 255.255.255.255 UH0 00 ppp0 169.254.0.0 0.0.0.0 255.255.0.0 U 1000 00 ppp0 0.0.0.0 10.37.79.0 0.0.0.0 UG0 00 ppp0 PPTP over PPP Destination Gateway Genmask Flags Metric RefUse Iface 192.168.7.128 10.37.69.0 255.255.255.255 UGH 0 00 ppp0 10.37.69.0 0.0.0.0 255.255.255.255 UH0 00 ppp0 82.153.174.82 10.37.69.0 255.255.255.255 UGH 0 00 ppp0 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 ppp1 10.37.79.0 is the PPP peer for the session, 82.153.174.82 is the public address of the VPN host, and 192.168.7.128 is its internal address within the VPN. The 3rd route entry above in PPTP mode was previously missing (provides the route for PPTP to send its packets to the server), so this is good. However, the first entry is wrong, and should not be there. The address 192.168.7.128 only exists within the VPN, so can't possibly be routed over the PPP gateway. With this route present, the VPN won't work, but if this route is deleted after the VPN is established, all hosts on the VPN can be contacted as expected. The two launchpad builds I used are: https://launchpad.net/~network-manager/+archive - I upgraded all the NM components with these versions https://launchpad.net/ubuntu/+source/network-manager-pptp/0.7~~svn20081015t024626-0ubuntu1.8.10.1/+build/792016 - I installed this over the top (apt says it's an earlier version, although it's a later date). This is dated 20 Nov, so I'm assuming there have been no fixes since? HTH, Rick ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Powersaving Patch for NetworkManager
drago01 wrote: On Wed, Nov 26, 2008 at 1:59 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 25, 2008 at 01:38:12PM +0100, Jan Kantert wrote: Hi, according to powertop Network Manager wakes up my cpu about once every two seconds. Thats does not sound much but on an idle desktop with 10 wake ups per seconds thats 5%. I wanted my laptop's cpu to stay longer in sleepstates so I wrote a little patch (against trunk) to replace g_timeout_add with g_timeout_add_seconds (where possible), which uses more rough granularity. This helps to aggregate timeouts and will statistically wake up the cpu less frequently. Sounds good. Curious, if you have collected data on how much of a powersaving win this patch brings? The patch itself won't save much power, but when other apps wake up less often too the cpu will spend more time idle and therefore save power. ?? - we should be able to quantify with powertop. Even if it doesn't save much power in the long run a wakeup once every 2 secconds (as quoted) vs. a wakeup once every 10 is an %80 reduction in wakeups. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Powersaving Patch for NetworkManager
James M. Leddy schrieb: drago01 wrote: On Wed, Nov 26, 2008 at 1:59 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 25, 2008 at 01:38:12PM +0100, Jan Kantert wrote: Hi, according to powertop Network Manager wakes up my cpu about once every two seconds. Thats does not sound much but on an idle desktop with 10 wake ups per seconds thats 5%. I wanted my laptop's cpu to stay longer in sleepstates so I wrote a little patch (against trunk) to replace g_timeout_add with g_timeout_add_seconds (where possible), which uses more rough granularity. This helps to aggregate timeouts and will statistically wake up the cpu less frequently. Sounds good. Curious, if you have collected data on how much of a powersaving win this patch brings? The patch itself won't save much power, but when other apps wake up less often too the cpu will spend more time idle and therefore save power. ?? - we should be able to quantify with powertop. Even if it doesn't save much power in the long run a wakeup once every 2 secconds (as quoted) vs. a wakeup once every 10 is an %80 reduction in wakeups. As I wrote: This patch helps to aggregate timeouts caused by glib applications. The more glib applications you use, which use g_timeout_add_seconds, the more wakeups will be saved. I patched some more apps on my desktop to use g_timeout_add_seconds. In average it helps to get my Thinkpad X61t from 10 wakeups to 8 wakeups, which is 20% reduction. Jan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NM probs under Fedora 10
Greetings - With EOL for Fedora 8 (which I have running on a number of machines), I decided to take one of them and try a clean install of the latest and greatest from Fedora (10 - Cambridge). After some fiddling, I got network up and running (standard RealTek NIC, fixed ip...), but something isn't letting NM play nice with my system. By default, I didn't install NM at all. However, if I grab it and the dependencies from yum repos, install it, I immediately lose networking, even though I didn't tell the system to use NM to manage anything! I can confirm that its something related to NM since as soon as I uninstall it (and related dependencies), networking pops right back on. I'm not entirely new to GNU/Linux, but usually don't fuss with networking much, since it generally works. However, I am somewhat concerned by the behaviour I just described above. Could someone more learned about NM (and that is most folks, at this point) give me some guidance about what to look for/check? Thanks very much in advance...apologies if this is below the usual level of discussion, but this is my first issue concerning NM. ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
