Re: Configuring DHCP
On Fri, May 2, 2008 at 5:50 PM, Dan Williams [EMAIL PROTECTED] wrote:
BTW, if debian puts interface-specific dhclient config files somewhere
else normally, I'm happy to have NM pass that location on the dhclient
command line for debian-based distros
instead. /etc/dhcp3/dhclient-wlan0.conf perhaps?
Here's a patch to fix it. Uses /etc/dhclient-$iface.conf on redhat,
/etc/dhclient.conf on suse and /etc/dhcp3/dhclient.conf on debian. Any
additions?
Tambet
diff --git a/ChangeLog b/ChangeLog
index b9e50bc..24c05cf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2008-05-16 Tambet Ingo [EMAIL PROTECTED]
+
+ * src/dhcp-manager/nm-dhcp-manager.c (dhclient_find_conf_file):
+ Implement.
+ (dhclient_run): Try to locate the dhclient.conf.
+
2008-05-15 Tambet Ingo [EMAIL PROTECTED]
Move crypto functions from nm-applet to libnm-util.
diff --git a/src/dhcp-manager/nm-dhcp-manager.c b/src/dhcp-manager/nm-dhcp-manager.c
index 3f338e0..16df573 100644
--- a/src/dhcp-manager/nm-dhcp-manager.c
+++ b/src/dhcp-manager/nm-dhcp-manager.c
@@ -1,3 +1,5 @@
+/* -*- Mode: C; tab-width: 5; indent-tabs-mode: t; c-basic-offset: 5 -*- */
+
/* nm-dhcp-manager.c - Handle the DHCP daemon for NetworkManager
*
* Copyright (C) 2005 Dan Williams
@@ -590,6 +592,35 @@ dhclient_child_setup (gpointer user_data G_GNUC_UNUSED)
setpgid (pid, pid);
}
+static char *
+dhclient_find_conf_file (const char *iface)
+{
+ char *file;
+
+ /* redhat */
+ file = g_strdup_printf (SYSCONFDIR /dhclient-%s.conf, iface);
+ if (g_file_test (file, G_FILE_TEST_IS_REGULAR))
+ return file;
+
+ g_free (file);
+
+ /* suse */
+ file = g_build_filename (SYSCONFDIR, dhclient.conf, NULL);
+ if (g_file_test (file, G_FILE_TEST_IS_REGULAR))
+ return file;
+
+ g_free (file);
+
+ /* debian */
+ file = g_build_filename (SYSCONFDIR, dhcp3, dhclient.conf, NULL);
+ if (g_file_test (file, G_FILE_TEST_IS_REGULAR))
+ return file;
+
+ g_free (file);
+
+ return NULL;
+}
+
static gboolean
dhclient_run (NMDHCPDevice *device)
{
@@ -628,11 +659,9 @@ dhclient_run (NMDHCPDevice *device)
goto out;
}
- conffile = g_strdup_printf (SYSCONFDIR /dhclient-%s.conf, device-iface);
- if (!conffile) {
- nm_warning (%s: not enough memory for dhclient options., device-iface);
- goto out;
- }
+ conffile = dhclient_find_conf_file (device-iface);
+ if (!conffile)
+ nm_warning (%s: Could not find dhclient configuration file., device-iface);
/* Kill any existing dhclient bound to this interface */
if (g_file_get_contents (pidfile, pid_contents, NULL, NULL)) {
@@ -657,8 +686,10 @@ dhclient_run (NMDHCPDevice *device)
g_ptr_array_add (dhclient_argv, (gpointer) -lf); /* Set lease file */
g_ptr_array_add (dhclient_argv, (gpointer) leasefile);
- g_ptr_array_add (dhclient_argv, (gpointer) -cf); /* Set interface config file */
- g_ptr_array_add (dhclient_argv, (gpointer) conffile);
+ if (conffile) {
+ g_ptr_array_add (dhclient_argv, (gpointer) -cf); /* Set interface config file */
+ g_ptr_array_add (dhclient_argv, (gpointer) conffile);
+ }
g_ptr_array_add (dhclient_argv, (gpointer) device-iface);
g_ptr_array_add (dhclient_argv, NULL);
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: multiple-device questions
On Thu, May 15, 2008 at 11:12 AM, Andrew Jorgensen [EMAIL PROTECTED] wrote: What are the plans for UI for controlling multiple-device behavior? Right now nm-applet just connects to all networks that have automatic configurations. This is potentially confusing. A few people have filed bugs or asked questions on this list. If the fastest device does not have a gateway defined (none offered by DHCP, link-local only, or none configured in static config) will NM choose a slower device for the default route? Yes. What signaling is given the listeners (like Pidgin or Evolution) when a device goes down but there are other devices up? NM offeres two ways for applications interested in network state. One is very convenient and easy to use but because of that not very detailed. It only signals changes when networking is disabled, (no active connections and a) connection is activating, activated, disconnected. The other API is a detailed one and is what nm-applet uses, for every change a signal is emitted. As there are many objects involved, it's a bit cumbersome to register all these signal handlers if the application only cares about if a connection is active or not. So in summary, if any application (pidgin, evolution) want, they can have a very detailed view of the state and signals when anything changes, but as of now, they use the simple version. Is the signaling different when it's the default route (or not) that has gone down? See above. What if, for example, evolution is connected to a mail server on a private network and the default route (on another network) goes down? Would it still receive a signal and go offline? See above. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-editor: Can't make existing configuration a system setting
On Tue, May 6, 2008 at 5:36 PM, Tambet Ingo [EMAIL PROTECTED] wrote: On Tue, May 6, 2008 at 4:50 PM, Michael Biebl [EMAIL PROTECTED] wrote: When I run the connection-editor from within nm-applet, it presents me a list of configured wlan networks (Auto foo, Auto bar, ...). I wanted to make one of those configurations a system setting, so I pressed Edit and checked the System setting checkbox. Unfortunately, this doesn't make nm-system-settings write a config file in /etc/NetworkManager/system_config. If I instead use Add, and check the System setting right from the start, nm-system-settings correctly creates a config file (which works properly). So it seems as if nm-applet doesn't convert an existing (user)configuration into a system setting configuration. Is this a known issue? It's known to me :) I sort of left it like that until the whole thing is secured with PolicyKit. Dan needs to approve my PK patches first, so you can blame him as well. :) Anyway, I'm glad it works properly with the add button for you, this is the first success story I hear. Should be fixed now. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: gsm: couldn't get secrets
On Fri, May 9, 2008 at 9:14 AM, Vitja Makarov [EMAIL PROTECTED] wrote: and let gsm setting ask for a pin/puk I implemented PIN asking for GSM devices yesterday. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Is NetworkManager ready for servers with may interfaces?
On Tue, May 6, 2008 at 3:43 PM, Kenneth Crudup [EMAIL PROTECTED] wrote: I'm still not quite sure how these end up in text files, what the filenames should be, nor what format. Can someone send me a tar file of their /etc/NetworkManager/system_config/ directory, please? The file names aren't important, but the the configuration files built by the keyfile plugin use connection names for file names. Since these files might contain passwords, they have to be owned by root and have 0600 permissions. Attached are two example files, one for ethernet, one for wireless with WPA-PSK security. It should be possible to create/modify/delete keyfile plugin files using the latest SVN nm-applet: when you open a connection properties page in connection-editor, there's a new checkbox System setttings. Checking it will push it to the system settings daemon. The version in SVN is not doing any authentication so everyone can do it, but I have patches to add PolicyKit support for it. Tambet Auto Ethernet Description: Binary data Auto it Description: Binary data ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-editor: Can't make existing configuration a system setting
On Tue, May 6, 2008 at 4:50 PM, Michael Biebl [EMAIL PROTECTED] wrote: When I run the connection-editor from within nm-applet, it presents me a list of configured wlan networks (Auto foo, Auto bar, ...). I wanted to make one of those configurations a system setting, so I pressed Edit and checked the System setting checkbox. Unfortunately, this doesn't make nm-system-settings write a config file in /etc/NetworkManager/system_config. If I instead use Add, and check the System setting right from the start, nm-system-settings correctly creates a config file (which works properly). So it seems as if nm-applet doesn't convert an existing (user)configuration into a system setting configuration. Is this a known issue? It's known to me :) I sort of left it like that until the whole thing is secured with PolicyKit. Dan needs to approve my PK patches first, so you can blame him as well. :) Anyway, I'm glad it works properly with the add button for you, this is the first success story I hear. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC8
On Mon, Apr 28, 2008 at 11:38 AM, Stefan Seyfried [EMAIL PROTECTED] wrote: I think that by just using the bits that are readily available, a much better user experience would be possible today. Sigh, I'm getting tired of hearing use umtsmon in every thread that has a word 3g or umts in it. Until umtsmon works with CDMA (Dan has explained it multiple times already), uses HAL for device discovery (opening random files in /proc and /sys is so last century), and most importantly, implements a DBus interface to control and receive status changes, NetworkManager simply can not use it. Not depending on Qt would certainly be a bonus too for a non-gui backend. So if you're interested in implementing these changes, feel free to ask for the details what exactly would be needed. Or if you just want to advertise umtsmon, please do it elsewhere. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: FC8
Umtsmon deliberately does not use HAL, since it is meant as a temporary solution until NM is ready, and it is intended to be usable on a little bit older systems that might not have the latest HAL. Umtsmon is not intended to be a backend for anything, and it would be pretty hard to hack it into that. Ah, sorry, I misunderstood you. Again: i was objecting the we cannot do this because the evil card maufacturers don't provide specs, which is the answer to every inquiry about proper 3G support and is, IMVHO plain FUD. It is possible. It has been done. I guess the truth is somewhere in the middle. The main reason why NM support for mobile devices is lacking is that it's almost good enough for now (0.7 release) (the PIN entering you mentioned is a small bug and can be easily fixed). Some other parts of NM aren't. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: SVN HEAD: Compilation error
On Thu, Apr 10, 2008 at 12:56 PM, Markus Becker [EMAIL PROTECTED] wrote: nm-system-config-hal-manager.c: In function 'nm_system_config_hal_manager_class_init': nm-system-config-hal-manager.c:306: error: 'nm_marshal_VOID__STRING_UINT' undeclared (first use in this function) Remove all the generated nm-marshal.[ch] files from all directories and rebuild. There was a different nm-marshal.[ch] in almost every source directory, it's now unified, but the build finds an old and obsoleted one. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Fix manual IP config
On Tue, Mar 18, 2008 at 12:36 PM, Dan Williams [EMAIL PROTECTED] wrote: On Tue, 2008-03-18 at 11:37 +0100, Helmut Schaa wrote: Nevertheless I want to give you an hypothetical scenario why I would prefer it to be set in real_act_stage3_ip_config_start: As far as I can see nm_device_set_use_dhcp is defined in nm_device.h and could therefore be used from some places outside nm_device.cpp. It would be possible to call nm_device_set_use_dhcp even if the device is down. Afterwards starting a non-dhcp connection on that device would lead to the initial problem. Setting it in real_act_stage3_ip_config_start would avoid such issues. Seems kind of odd; I can't think why we'd want to set it when the device is down? The use-dhcp parameter should _only_ be set during activation, based on the 'method' parameter of the activating connection's ip4-config setting. When the activation cancels, or the device is deactivated, the use-dhcp setting should be cleared, because the next time the device activates, it might have a different connection, and therefore have a different 'method' parameter in the ip4-config setting, and therefore use autoipv4 or static addressing instead of DHCP. Well, nm_device_set_use_dhcp() shouldn't really be public, it's declaration should be in nm-device-private.h instead. The only allowed callers should be NMDevice and it's subclasses. Or maybe not even subclasses and the function should be static. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Fix manual IP config
2008/3/17 Helmut Schaa [EMAIL PROTECTED]: I had some problems with manual IP configuration being ignored by NM. Attached patch for trunk fixes it for me. I don't understand why or how this patch could fix the problem though. The call you added, nm_device_set_use_dhcp (self, FALSE); makes sure there's no DHCP manager associated with the device and that's already the state NMDevice has prior to activation state 3. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: pptp can't compile and reconnection
On Mon, Mar 17, 2008 at 10:02 AM, Charly Liu [EMAIL PROTECTED] wrote: The 12th march I downloaded the svn version of NetworkManager. I could compile everything except pptp because it says that I don't have the file dbus-dict-helper.h. I searched a little bit and I saw that in previous snapshots it has it (I think in svn 2958 or something like this). Is it normal that i don't have it or how can I get it? Another bug that I noticed was that when I disable the wireless connection and then enable again, it doesn't reconnect to the previous AP I was connected to (at least in my pc). I will look this week if I can fix it (if there is any problem, hehe). One part of the 0.7 rework we did was to change the way VPN backends (or modules) worked. VPNC and openvpn backends got changed for the new API, PPTP didn't. So it won't work at all right now. It basically needs a rewrite: to use the new APIs of NetworkManager, to not use it's own ppp manager (NM now provides one) and to remove all the hacks it had to support random ppp connections that NM didn't support in 0.6. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Fix manual IP config
On Mon, Mar 17, 2008 at 11:02 AM, Helmut Schaa [EMAIL PROTECTED] wrote: Why not call it in real_act_stage3_ip_config_start as it is done when using DHCP? That would be much clearer, no? It's much cleaner to not keep dhcp manager around when a device is deactivated. It's not only cleaner, it's a bug not to do it there. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: API changes
On Thu, Mar 13, 2008 at 9:29 AM, Will Stephenson [EMAIL PROTECTED] wrote: org.freedesktop.NetworkManager Methods: #1 ActivateDevice ( o: device, s: service_name, o: connection, o: specific_object ) → nothing suggestion: move to org.freedesktop.NetworkManager.Device.Activate(s: service_name, o: connection, o: specific_object ) → nothing rationale: Helmut told me that this had already been discussed, and that because you could imagine Connection.Activate( Device ) or Device.Activate( Connection) it was decided to put it on the manager. If this was communicated properly, this is a worst of all compromise. Since Connection is on the settings service, the action can't be carried out there, so stay object-oriented and move this to Device. As I'm wrapping NM in Solid for KDE 4, I'll probably move this method onto the Device class anyway, but moving it in NM would be better for both projects IMO. It was never a discussion between Connection.Activate(Device) vs Device.Activate(Connection). The current solution isn't a compromise either, it's just the way things have to be right now. NMManager is the thing that has access to available settings and devices, hence it's the thing that can tie them together for activation. Device.Activate(connection_path) is not possible since device can't translate that connection_path to Connection without the help of NMManager. It can't do that since NMManager has to contain the list of devices, and circular dependencies are much bigger OOP offenders than what you suggest. The reason why it was pretty much impossible to add new device types to 0.6 branch was because of no class hierarchy, everything just called everything and to add a new device type meant changing almost all source files. With the strict hierarchy (that I've been defending very hard, and still do), adding a new device means implementing a subclass of NMDevice, a subclass of NMSetting and a registration function in NMHalManager. I'm not willing to give up all this just to have Device.Activate(Connection). #2 errors: org.freedesktop.NetworkManager.Error.ConnectionActivating Another connection is already activating or the same connection is already active. org.freedesktop.NetworkManager.Error.ConnectionActivating Does this mean the same connection is already activating or is another connection activating on this device? Suggestion: split into org.freedesktop.NetworkManager.Error.ConnectionAlreadyActive org.freedesktop.NetworkManager.Error.ConnectionActivating Although I'm not sure when this error would be raised, since a client might want to interrupt a connection attempt (maybe started with bad parameter, maybe it's going wrong and failing to error). #3 Sleep ( b: sleep ) → nothing Control the NetworkManager daemon's sleep state. When asleep, all interfaces that it manages are deactivated. Parameters sleep - b Indicates whether the NetworkManager daemon should sleep or wake. suggestion: It's not clear from the method name what this does SetSleepState( b: asleep ) perhaps? It would be even clearer to rename it to EnableNetworking(b: enabled). #4 enum: NM_STATE_CONNECTING = 2 The NetworkManager daemon is connecting a device. What does this mean when one device is already active and another is connecting? The NMState enum is not 100% accurate in case of multiple devices and it isn't meant to. It reflects the best state of NM. The reason behind it is to give easier API for applications that only care if the machine has network connection or not. So for your specific question, if a device is active and another one is activating, the NMState reamains NM_STATE_CONNECTED. If an app wants more information, it can always get NMManager, it's list of devices and the state of each device. org.freedesktop.NetworkManager.AccessPoint #5 roperties: HwAddress - s - (read) The hardware address of the access point. suggestion: make this uint64 type=t? IP addresses are uints, and uint64 fits both 48 bit and 64 bit MAC addresses, and is smaller than the unicode string needed for a macaddress. The data type for it in the kernel is struct ether_addr, just because it fits in a uint64 doesn't mean it's a good data type for it. There's no calculations to perform on it, the only useful operation on it would be to print it out. Then why bother with the conversions to save a few bites on communication when you're going to waste these same bites when you're actually going to do anything (display) it? org.freedesktop.NetworkManager.Device.Wired Properties: #6 HwAddress - s - (read) Hardware address of the device. Suggestion: change to 't' as above Just as above. #7 org.freedesktop.NetworkManagerSettings Signals: NewConnection ( o: connection ) Suggestion: rename to ConnectionAdded to be consistent with NetworkManager.DeviceAdded Sounds good to me. #8 Where is ConnectionRemoved
Re: API changes
On Thu, Mar 13, 2008 at 11:48 AM, Dan Williams [EMAIL PROTECTED] wrote: On Thu, 2008-03-13 at 18:17 +0100, Will Stephenson wrote: I understood the applet merges APs in the same network for presentation to the user, is that what all the calls to ether_aton() in the NM and applet sources are doing? And HAL uses uint64 for mac addresses. At a guess, you're converting from that, using hex-and-colons for dbus transport, converting it to ether_addr for comparisons, and converting it back again for the UI. NM pulls it right out of SIOCGIFHWADDR which is struct ether_addr (ie, char[6]). It does get converted from struct ether_addr to a string with ether_ntop for D-Bus transport. 1/2 dozen to one, 6 to another. I think the decision to be made is to either leave it as-is (ie, strings), or convert the type to byte array with the exact length of the device type's hardware address (char[6] for 802.11, 802.3, and 802.15, char[7] for GSM CDMA). That's an easy decision. Since there isn't significant space savings between byte array and string (byte array with a couple of colons and '\0') and there's nothing else for UIs to do with these other than print out (as strings), there's no reason to change anything. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp support
On Wed, Mar 5, 2008 at 3:35 PM, Johann B. Gudmundsson [EMAIL PROTECTED] wrote: Can Vitja Makarov or his code help speeding up support for PPTP (VPN) into NM. So what exactly are we still discussing here? I've repeatedly assured here that we can change NMPppManager to do exactly what is needed. Let's stop this thread and produce some patches! Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
PPPoE
Heya,
After all these ppp manager mails I decided to see what really is
missing from NM to add some new PPP based connections (NM supposedly
supported only PPP over serial line). I chose PPPoE since I need to
implement it anyway. Turns out, it's as easy as I imagined it would
be. Well, almost. There's one issue that needs fixing. The current
interaction between ppp manager and pppd plugin is over dbus and
plugin emits signals when stuff changes and manager listens for these.
It has to be the other way around (manager has to register a
well-known service on dbus and plugin needs to call it's methods).
Otherwise, there's no way the plugin can ask for credentials when it
needs them for CHAP or PAP. So that and UI are missing for now.
Attached are the patches to implement PPPoE. 407 insertions, 16 deletions.
Tambet
From 1d894148f3e561efa47533f68dd36cae8e4ffd69 Mon Sep 17 00:00:00 2001
From: Tambet Ingo [EMAIL PROTECTED]
Date: Wed, 5 Mar 2008 20:48:19 -0600
Subject: [PATCH] Implement NMSettingPPPOE.
diff --git a/libnm-util/Makefile.am b/libnm-util/Makefile.am
index ddbac0b..f95ace6 100644
--- a/libnm-util/Makefile.am
+++ b/libnm-util/Makefile.am
@@ -18,6 +18,7 @@ libnm_util_include_HEADERS = \
nm-setting-connection.h \
nm-setting-ip4-config.h \
nm-setting-ppp.h \
+ nm-setting-pppoe.h \
nm-setting-serial.h \
nm-setting-gsm.h \
nm-setting-cdma.h \
@@ -35,6 +36,7 @@ libnm_util_la_SOURCES= \
nm-setting-connection.c \
nm-setting-ip4-config.c \
nm-setting-ppp.c \
+ nm-setting-pppoe.c \
nm-setting-serial.c \
nm-setting-gsm.c \
nm-setting-cdma.c \
diff --git a/libnm-util/nm-connection.c b/libnm-util/nm-connection.c
index d44dd6a..074a8f0 100644
--- a/libnm-util/nm-connection.c
+++ b/libnm-util/nm-connection.c
@@ -9,6 +9,7 @@
#include nm-setting-connection.h
#include nm-setting-ip4-config.h
#include nm-setting-ppp.h
+#include nm-setting-pppoe.h
#include nm-setting-wired.h
#include nm-setting-wireless.h
#include nm-setting-wireless-security.h
@@ -68,6 +69,7 @@ register_default_settings (void)
{ NM_SETTING_GSM_SETTING_NAME, NM_TYPE_SETTING_GSM },
{ NM_SETTING_CDMA_SETTING_NAME, NM_TYPE_SETTING_CDMA },
{ NM_SETTING_PPP_SETTING_NAME, NM_TYPE_SETTING_PPP },
+ { NM_SETTING_PPPOE_SETTING_NAME, NM_TYPE_SETTING_PPPOE },
{ NM_SETTING_VPN_SETTING_NAME, NM_TYPE_SETTING_VPN },
{ NM_SETTING_VPN_PROPERTIES_SETTING_NAME,NM_TYPE_SETTING_VPN_PROPERTIES },
{ NULL }
diff --git a/libnm-util/nm-setting-pppoe.c b/libnm-util/nm-setting-pppoe.c
new file mode 100644
index 000..3bbe2e4
--- /dev/null
+++ b/libnm-util/nm-setting-pppoe.c
@@ -0,0 +1,123 @@
+/* -*- Mode: C; tab-width: 5; indent-tabs-mode: t; c-basic-offset: 5 -*- */
+
+#include nm-setting-pppoe.h
+
+G_DEFINE_TYPE (NMSettingPPPOE, nm_setting_pppoe, NM_TYPE_SETTING)
+
+enum {
+ PROP_0,
+ PROP_USERNAME,
+ PROP_PASSWORD,
+
+ LAST_PROP
+};
+
+NMSetting *
+nm_setting_pppoe_new (void)
+{
+ return (NMSetting *) g_object_new (NM_TYPE_SETTING_PPPOE, NULL);
+}
+
+static gboolean
+verify (NMSetting *setting, GSList *all_settings)
+{
+ NMSettingPPPOE *self = NM_SETTING_PPPOE (setting);
+
+ if (!self-username) {
+ g_warning (Missing username);
+ return FALSE;
+ }
+
+ return TRUE;
+}
+
+static GPtrArray *
+need_secrets (NMSetting *setting)
+{
+ NMSettingPPPOE *self = NM_SETTING_PPPOE (setting);
+ GPtrArray *secrets;
+
+ if (self-password)
+ return NULL;
+
+ secrets = g_ptr_array_sized_new (1);
+ g_ptr_array_add (secrets, NM_SETTING_PPPOE_PASSWORD);
+
+ return secrets;
+}
+
+static void
+nm_setting_pppoe_init (NMSettingPPPOE *setting)
+{
+ ((NMSetting *) setting)-name = g_strdup (NM_SETTING_PPPOE_SETTING_NAME);
+}
+
+static void
+set_property (GObject *object, guint prop_id,
+ const GValue *value, GParamSpec *pspec)
+{
+ NMSettingPPPOE *setting = NM_SETTING_PPPOE (object);
+
+ switch (prop_id) {
+ case PROP_USERNAME:
+ g_free (setting-username);
+ setting-username = g_value_dup_string (value);
+ break;
+ case PROP_PASSWORD:
+ g_free (setting-password);
+ setting-password = g_value_dup_string (value);
+ break;
+ default:
+ G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
+ break;
+ }
+}
+
+static void
+get_property (GObject *object, guint prop_id,
+ GValue *value, GParamSpec *pspec)
+{
+ NMSettingPPPOE *setting = NM_SETTING_PPPOE (object);
+
+ switch (prop_id) {
+ case PROP_USERNAME:
+ g_value_set_string (value, setting-username);
+ break;
+ case PROP_PASSWORD:
+ g_value_set_string (value, setting-password);
+ break;
+ default:
+ G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
+ break;
+ }
+}
+
+static void
+nm_setting_pppoe_class_init (NMSettingPPPOEClass *setting_class)
+{
+ GObjectClass *object_class = G_OBJECT_CLASS (setting_class);
+ NMSettingClass *parent_class = NM_SETTING_CLASS (setting_class);
+
+ /* virtual methods */
+ object_class-set_property = set_property;
+ object_class-get_property
Re: ppp support
On Mon, Mar 3, 2008 at 11:01 AM, Vitja Makarov [EMAIL PROTECTED] wrote: But no GUI for now. I'm asking NM developers about collaboration, merging or so on. Any criticism is welcome. I don't really understand the need of this project at all. NM already contains a class for that, it even has the exact same name as your project. Why not just improve that? That should take care of collaboration and there won't be a need for merging. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Finally, NetworkManager CLI
Also, I forgot to mention, if you see an ugly error with every command looking something like this: ERROR:dbus.proxies:Introspect error on :1.79759:/org/freedesktop/NetworkManager/VPN/Connection/9: dbus.exceptions.IntrospectionParserException: Error parsing introspect data: class 'xml.parsers.expat.ExpatError': mismatched tag: line 29, column 6 it means you should make sure you have the following patch for bus-glib http://gitweb.freedesktop.org/?p=dbus/dbus-glib.git;a=commit;h=3f6e2c0c76d3643a1823b5ea7c8f5486a6b448de It's not in any release yet. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: New features in the 0.6 branch
On Feb 12, 2008 4:06 PM, Michael Biebl [EMAIL PROTECTED] wrote: I'm running 3307 from NETWORKMANAGER_0_6_0_RELEASE and 521 from network-manager-applet-0-6 now. I haven't experienced a crash since then. Yay! nm-applet now also shwows the Enable wireless network in the context menu greyed out, so I'm no longer able to disable wireless independently from the global enable network option. That's odd... what's your killswitch state, and were there any messages in the logs about killswitch stuff? Hm, I can't reproduce that anymore myself. So it's probably not worth for further investigation. I fixed a crasher bug I introduced with my 802.1x wired auth patch on 2008-02-05, that's probably what you were seeing. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM DBUS api documentation build system
On Feb 5, 2008 8:46 AM, Will Stephenson [EMAIL PROTECTED] wrote: snip I haven't actually added any api documentation yet. I'm working on supporting NM 0.7 in KDE 4 and would do so as I grok 0.7. The patch just replicates the status quo with the ability to add api docs. The system can also add a make check target to assure the docu generation is working but I haven't adapted/copied that yet. Another question is, are you interested in async glib binding support? The system can apparently generate separate async introspection xml but I haven't adapted that either yet as I'm not familiar with the glib bindings. I've tested this locally. Dan, Tambet: what do you think about integrating it? It would make NM client developement much easier. While I'd like to have always up to date documentation, I'm not sure I like this. The patch you sent only removes the introspection XML we currently have and adds some XSLT which I can't read (and thus maintain). It'll make development easier only if someone actually writes that documentation, just converting to more magic makes things harder to understand. And again, I like having documentation as much as anyone, but since we have two developers in total (who are busy with maintenance work for a lot of time), I personally would rather write code. So if anyone wants to help with documentation, it could live in a text file for now. When it has enough information, and if Dan feels comfortable maintaining XSLT, I wouldn't have anything against the proposed solution. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: New features in the 0.6 branch
On Feb 4, 2008 4:24 AM, Gabriele Monti [EMAIL PROTECTED] wrote: Thanks a lot, I really needed wired authentication! I compiled and packaged the 0.6 branch for Ubuntu and it works really fine! Thanks for trying it out, I'm glad it works! Now I don't need a script and a manually edited configuration file anymore! I found no critical bug so far, but I'd like to submit a feature request: When I connected to the authenticated network for the first time I gave it a name (let's say network a). I noticed that the keyring manager (and seahorse as well) added the to its stored ones. Now, whenever I plug the cable to that network I see a new network a in the network list but when I click on it I'm asked for user and password again. Is there a way to let it store somewhere (just as it happens with wireless networks)? It is supposed to work like wireless and get the secrets from keyring automatically, sounds like there's a bug somewhere. I'll look into it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to use the pppd plugin from svn?
On Dec 19, 2007 9:46 PM, van Schelve [EMAIL PROTECTED] wrote: After restarting hald, NetworkManager and the modem itself I see three entries GSM Modem in the NetworkManager. But how do I have to configure them to create a UMTS connection? There was a bug in NetworkManager that added a GSM Modem entry for each serial interface the modem has. It was fixed a couple of weeks ago in the SVN. There's no UI for configuring the modem connections, the applet creates settings with default values and if that doesn't work for your connection, then it doesn't work. You could use gconf-editor to change the phone number or to set the PIN, other settings are currently ignored by NM. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Dec 4, 2007 4:17 PM, Jon Escombe [EMAIL PROTECTED] wrote: Good stuff, got connected first time ;) Only issues were that it didn't set up resolv.conf, and also added three entries to the applet menu (as the card presents three ports). Both of these issues should be fixed in the SVN now. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Dec 4, 2007 3:28 PM, Jon Escombe [EMAIL PROTECTED] wrote: I've just built from the latest SVN keen to give the UMTS support a try. Do you have a list of the gconf entries needed to get up and running? nm-applet creates the gconf entries with default values when you ask it to connect and there's no connections suitable for umts cards. That doesn't mean thought that things would work out of the box - NM gets all it's information about network devices from HAL, but HAL does not tell us if a serial device is: a modem? what type of modem? In case of GSM cards, is it a data device or monitoring/command device? Until someone adds all that data to HAL, I have a simple hack I use at the moment. The attached .fdi file adds a capability 'modem' for the serial device which is my modem. So if you want to test NetworkManager's GSM card support, you'll need to modify this file to contain the ids of your modem, copy it to /usr/share/hal/fdi/information/20thirdparty/ and probably restart hal. For the real solution, we need to discuss where to draw the line for what should happen in HAL and what in NM. From my (biased) point of view, HAL should do all the work and tag all types of modem devices with different properties. Tambet 10-3g-modem.fdi Description: Binary data ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Dec 4, 2007 4:17 PM, Jon Escombe [EMAIL PROTECTED] wrote: Good stuff, got connected first time ;) Awesome! You're the first person I know who got it working! :) Only issues were that it didn't set up resolv.conf, Yeah, that part is a bit broken. NM usually (in case of VPN) prefers to do it but for now, I let pppd take care of it and I have no idea why it failed for you. and also added three entries to the applet menu (as the card presents three ports). If you first insert the card first and then start NM, it'll add only one :) I known about it, I'll try to fix it. Thanks, Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Dec 4, 2007 5:20 PM, Dan Williams [EMAIL PROTECTED] wrote: I assume there's a way to get the DNS info and other stuff out of pppd and push it to NM so that NM can handle the stuff instead? Oh, yeah. The pppd module we have already does it and sends all the info (like ip, netmask, routes, dns, even wins) to NM. NM however just ignores it right now (see the nice FIXME: at nm-serial-device.c:ppp_ip4_config()). The main reason I haven't done it is yet is that I don't think libnl functions we have for setting all sorts of stuff (that's not about DNS though) work with ppp device. I'm not sure though. Anyway, once that fixme is fixed, we need to make pppd to not set it somehow and it's been a long time since I looked at it and I don't remember how easy that is. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Unmount drives before closing PPTP vpn
On Dec 2, 2007 12:26 AM, mr wizard [EMAIL PROTECTED] wrote: I'm running Ubuntu 7.10 at the moment and I'd like to unmount some network drives when I close my PPTP VPN connection. I found NetworkManagerDispatcher, but that doesn't seem to care about VPNs or ppp connections at the moment. That is correct. Unfortunately, there is no solution for it right now other than writing a DBUS signal listener yourself. Tambet Am I missing something, is there another way to do this or should I just wait until it gets fixed? I have looked at the code but I got lost pretty quickly between the different daemons, programs and plugins (also, I've never worked with DBUS). Regards, Ronald ___ 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: RFC 4833 / TimeZone by DHCP
On Dec 3, 2007 11:06 AM, Dominique Leuenberger [EMAIL PROTECTED] wrote: As an international traveling user (mostly inside our company) I would like very much to have the ability to have an accurate, local time on my system wherever I am. RFC 4833 aims directly at this and allows network administrators to push out via DHCP the current time zone (which can easily configured). Would it be possible to implement this into our NM? NM just gained the ability to support static routes from DHCP (http://mail.gnome.org/archives/networkmanager-list/2007-November/msg00173.html), if anyone's interested in adding time zone support, using that patch as a template should make it pretty easy. The only tricky part may be the actual setting of the time zone in such a way that it would work on all distros. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Nov 29, 2007 1:47 AM, Bastien Nocera [EMAIL PROTECTED] wrote: I'll be more than happy writing the GPRS bits of it. Awesome! Is there any Bluetooth related code in the code you're writing? No, the current code only handles communications with serial devices like opening, closing, configuring, sending (AT) commands, waiting for any/certain replies, etc. It also implements a GSM (while currently called UmtsDevice, we're looking for a better name for it) device that is implemented on top of serial device and handles the specific AT commands required to establish a connection. Although I have no idea how bluetooth devices work, I assume there's some magic that needs to happen and as a result there will be a serial device that takes AT commands? If so, then bluetooth (NM) device could be just a subclass of the current GSM device, do it's magic in the initialization phase and let the GSM device take care of everything else. I'm thinking specifically of the ppp-manager having a special casing for devices that look like Bluetooth addresses, and having it create rfcomm devices as appropriate (as pppd still doesn't have any native Bluetooth support). The way things currently work is that we call pppd only after the serial connection is already established. Can this be done with bluetooth devices as well? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Nov 27, 2007 6:40 PM, vikram b [EMAIL PROTECTED] wrote: Hi, I would like use svn trunk's code to setup ppp connection , lets say for dial up (gprs etc). As Dan already said, I have code to drive gsm data cards and we hope to get it to SVN later this week, even if it means there's no way to configure it yet from the UI (the currently missing part). Could anybody give me where to start . i mean i couldn't see things in libnm etc. nm_ppp_manager_start() is a func i could see . Are we planning to support dbus methods to start/manage pppd connections ? (like in nm-vpn-manager.xml: method name=Connect ) any plans for same methods for ppp ? or what is the alternate way to do ppp connection now ? No, the ppp manager is internal to NetworkManager and thus isn't going to be exposed directly over dbus. What exactly do you want to achieve? NetworkManager provides a way to activate/deactivate devices, just starting random programs (like pppd) is a side effect :) Instead, there's a new device type, NMUmtsDevice which can be activated the same way as other device types (NMManager.ActivateDevice ()). One of it's arguments is a NMConnection object which always contains a list of NMSetting subclasses, each device type has it's own required settings. For the NMUmtsDevice, the required settings are NMSettingPPP (to pass ppp options), NMSettingSerial (to configure the serial port) and NMSettingUmts (for gsm specific settings like phone number, APN, username, password, etc). Once the NMUmtsDevice receives the activation request, it opens and configures the serial port, sends the required AT commands and starts pppd. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Nov 28, 2007 7:02 AM, vikram b [EMAIL PROTECTED] wrote: Thanks ! Would wait for his resp. Just a quick question . Are we going to have CAPI plugins for pppd in near future ? which is req. for the isdn dialup etc. I don't know what CAPI is, but the work I've done for gsm card support is done in a way to support all types of serial devices. There's a base class NMSerialDevice which should be a suitable base class for any serial device. Right now, only NMUmtsDevice is derived from it. There's also a ppp-manager which knows nothing about devices or their types. So we should have all the pieces to easily add support for any type of serial devices like cdma, regular land line modems, and isdn cards. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and Madwifi connection loss
On Nov 27, 2007 7:47 PM, Darren Albers [EMAIL PROTECTED] wrote: card I show one bar and get disconnected frequently. There was a hack posted by Robert Love almost two years ago that Translated (If that is the right way to describe it) the Madwifi signal reporting into a rough approximation of what most cards use. This helped make the cards more usable but still not enough to compare with other cards. The hack lived in suse packages but users reported the drivers changed and because of that hack, NM always showed 100% signal strength. So apparently the driver is fixed now. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Nov 28, 2007 2:38 PM, Jon Escombe [EMAIL PROTECTED] wrote: Thanks, looking forward to trying it out.. Assuming we can configure a connection manually by putting the right entries into gconf? Yeah, exactly. That's how I've tested it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ppp using NM
On Nov 28, 2007 5:01 PM, Dan Williams [EMAIL PROTECTED] wrote: Yes, that'll work; though for secrets you might need to write some C bits to push the PIN or whatever into the keyring. But if you don't have a PIN and since most networks don't care about the username/pass anyway, it may just work. Naah, setting PIN is even easier, you just need to add the pin key/value to gconf manually and it'll use it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IPADDR/PREFIXLEN
On Nov 26, 2007 11:38 PM, Michal Zugec [EMAIL PROTECTED] wrote: I checked also other distributin sources and the same problem is everywhere. Before I start to play with it I want to ask - anybody solved it yet? Or I need to start from scratch? My take (being the assignee of the bug on novell bugzilla) is that it's not worth to spend time on it for the stable branch (0.6.x). There's an easy workaround, just use the first form. For the future releases of NM (from 0.7 branch), our goal is to get rid of the whole src/backends directory. It currently does two things: reads configuration from the distro specific configuration files and to commit configuration changes in distro specific way. For writing, it has proved to not have a lot of point and it's getting changed to use libnl directly. For reading, there's a system settings daemon Dan committed just last week, but it's a work in progress and isn't in the state yet where you could just fix this specific bug. (My personal opinion: Even longer term solution, let's not use distro specific shell scripts at all) Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: IEEE 802.x authentication for wired network
Hello, On Nov 21, 2007 8:14 PM, Gabriele Monti [EMAIL PROTECTED] wrote: I was wondering if you plan to introduce support for 802.x authentication on wired network. Yes, I've started looking into it more than once. Sadly, every time I've finished before writing any line of code - Looking for the information on how to set up the authenticating router and especially radius have been too much. If anyone could write up a simple howto for me on how to set up the other end (preferably that howto wouldn't have the word 'radius' in it) using hostap, I promise I'll write the NetworkManager support. Bonus points if the howto describes how to set it up on openwrt. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Subversion NetworkManager not operational (for me).
On Nov 15, 2007 3:47 PM, Fred Clausen [EMAIL PROTECTED] wrote: So, while at work today (where I am using wired ethernet), I decided to check out the latest svn sources and compile them. I used the following autogen line: ./autogen.sh --prefix=/usr --with-dbus-sys=/etc/dbus-1/system.d\ --with-wpa_supplicant=/sbin/wpa_supplicant\ --with-dhcdbd=/usr/sbin/dhcdbd --with-distro=debian There are no --with-wpa_supplicant and --with-dhcdbd configure flags anymore. This built fine and I also built the latest nm-applet. However, when I start NetworkManager is does not see any Wireless access points and cannot get a DHCP lease from the wired ethernet. You need wpa_supplicant = 0.5.8 built with dbus support (see if wpa_supplicant --help shows '-u' flag). NM doesn't try to start it so you'll either need to start it manually (as root, with -u) before running NM or use dbus 1.1.x which has system service activation. (For that to work, you'll need patches from fedora 8 wpa_supplicant package until Dan gets them upstream). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Bluetooth
On Nov 15, 2007 12:13 PM, vikram b [EMAIL PROTECTED] wrote: What kind of Bluetooth support is available with current NM ? Is it only DUN profile ? Is there any know integration of Infrared with Network manager There is no bluetooth or infrared support in NetworkManager yet. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Subversion NetworkManager not operational (for me).
On Nov 15, 2007 5:10 PM, Fred Clausen [EMAIL PROTECTED] wrote: I have dbus 1.1.1 installed and my wpa_supplicant does support the -u flag. However, this still does not explain why the wired tg3 connection is not started. If you look at the logs, it even gets a DHCP lease but NM does not realise this for some reason. Any further suggestions to get wired ethernet working? Then I will work on solving the wireless problem. Do you have a default script line in /etc/dhclient.conf? Something like: script /sbin/dhclient-script; If so, comment it out. dhclient doesn't let you override configuration values from command line if they are already defined in the configuration file - something that NM needs. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-pppd-plugin.so: strange build
On Nov 5, 2007 3:49 PM, Michael Biebl [EMAIL PROTECTED] wrote: Sure. Patch is attached. Thanks! It uses -avoid-version (omit so-versioning) and -module (make so dlopen'able). Currently it installs into libdir. As I said, pkglibdir would probably better. Yeah, pkglibdir would be the correct location. But as you said yourself, it's currently not used anywhere, so I'm not entirely sure what's actually best. Maybe it would make sense, to comment it out completely in Makefile.am until it's actually used. It should become used very soon, so there's probably no point in disabling it now. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-pppd-plugin.so: strange build
On Nov 5, 2007 2:11 AM, Michael Biebl [EMAIL PROTECTED] wrote: looking at the NM 0.7 source, I noticed that the pppd plugin is built as executable (nm_pppd_plugin_PROGRAMS = nm-pppd-plugin.so) with a very strange *.so file ending and an attempt to transform it in some sort of shared object by using -shared and -fPIC. Why isn't lib_LTLIBRARIES used at first place for compiling the nm-pppd plugin? As it's a private plugin, pkglib_LTLIBRARIES would probably be even better. Could someone shed some light on this current odd situation of the pppd plugin? The Makefile.am content is just copied from somewhere, most probably from pptp vpn module. It doesn't really matter much since it's currently not used by anything. Feel free to send patches to improve it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: How to change the level of debug info
On Nov 5, 2007 5:34 AM, Charles Li [EMAIL PROTECTED] wrote: I wanna view the info level's log in /var/log/NetworkManager, I found that's call g_message(), so how can I make G_LOG_LEVEL_MESSAGE work outside the process, not recompiling it? NetworkManager uses syslog so it's a matter of configuring the syslog daemon to change the threshold. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Merge network manager with network monitor
On Nov 1, 2007 12:13 PM, Simon Geard [EMAIL PROTECTED] wrote: I've got a wireless connection which drops out from time to time, but often recovering before NM notices. Obviously I'd rather that didn't happen at all, but when it does, the network monitor applet shows pretty much instantly when the connection is out, and when it comes back. So I keep both of them on the panel. Having just one would be nice... 0.6 branch is declared stable so it's unlikely it'll get new features. In 0.7 branch NM notifies the applet when anything changes (instead of applet polling NM in every X seconds), so there's no chance the applet would not notice it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: static address status
On 10/19/07, Dan Williams [EMAIL PROTECTED] wrote: On Fri, 2007-10-19 at 14:41 -0400, jacob berkman wrote: i was wondering what the current status of static address configuration was. there is an IP addresses tab in nm-connection-editor, is that for this, or something slightly different? is it close to being done, or is there only some ui with not much backend work? Tambet is about to land patches that make NM itself respect static IP; maybe coordinate with him? I just committed it. We ended up with a bit different structure than what's in http://live.gnome.org/NetworkManagerConfigurationSpecification (Dan: hint! hint!). There's no 'ipv4-address-X' settings and 'ipv4' has the format: manual : bool dns : array/uint32 dns-search : array/string addresses : array/array/uint32 Addresses is an array containing a tuple per IP address where the first item is address, second is netmask and an optional third member containing the gateway. Here's an example: addresses : [ (1, 2, 3), (4, 5) ] Which translates to: address1: 1 netmask1: 2 gateway1: 3 address2: 4 netmask2: 5 (no gateway) where would be a good place to start for working on this? Dan already answered that, I'd just like to add that it's going to suck to store the addresses to gconf - gconf supports only collections of basic types, so arrays of arrays wouldn't work. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trying to start the supplicant...
On 10/16/07, krash [EMAIL PROTECTED] wrote: no i haven't enabled dbus in config file because i have used a original package. Now i have compiled with options and it works!! If i start wpa_supplicant daemon before NetworkManager, all works, but isn't dbus capable to start wpa_supplicant automatically? In other post i see that there is a file in /usr/share/dbus-1/services. I don't have it. What is the content? If you want to start wpa_supplicant automatically, you'll need (unstable) dbus = 1.1.2 which supports system service activation. The content of the activation file is: #cat /usr/share/dbus-1/system-services/fi.epitest.hostap.WPASupplicant.service [D-BUS Service] Name=fi.epitest.hostap.WPASupplicant Exec=/usr/sbin/wpa_supplicant -u User=root Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trying to start the supplicant...
On 10/16/07, krash [EMAIL PROTECTED] wrote: my version of wpa_supplicant is 0.5.7 but don't have -u option. Do i search new version? Yes, it means your wpa_supplicant is compiled without dbus support and won't work with NetworkManager 0.7. If you decide to build wpa_supplicant from sources, it needs a CONFIG_CTRL_IFACE_DBUS=y line in .config file. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Oddities with NM 0.7
On 10/12/07, Clark Williams [EMAIL PROTECTED] wrote: I've been having trouble with NetworkManager 0.7 on my rawhide laptop (T60 with iwl3945 wireless part running latest iwlwifi drivers), ever since it came out. The main symptom I'm seeing is the following in syslog: Oct 13 02:30:57 localhost NetworkManager: info Trying to start the supplicant... Oct 13 02:32:03 localhost NetworkManager:last message repeated 11 times NM tries to start wpa_supplicant using dbus-1.1 system service activation and fails. Make sure you have dbus-1.1 installed and running. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Note about device activation in current trunk...
On 9/29/07, Helmut Schaa [EMAIL PROTECTED] wrote: ActivateDevice would then take the device's object-path and the connection's object-path as arguments, right? Internally, yes, but it will not be exposed over dbus. Not sure about this. The interface would be much more obvious if Activate would stay as a device-method. Not really. Devices don't have any stored connections you reference by path and service_name argument, NMManager has. It would make just as much sense as NMConnection.Activate(o device_path) than the other way around. Since the manager keeps track of devices and connections and thus ties them together, it's the obvious place for the activation. The reason why it was NMDevice.Activate(connection) was that it used to make sense when the whole connection was sent to the device with activation request. The problem was, that would not work with system connections (pre-configured by system administrator) where only the connection path is available for the user activating the connection. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Note about device activation in current trunk...
On 10/1/07, Helmut Schaa [EMAIL PROTECTED] wrote: Am Montag, 1. Oktober 2007 08:02:18 schrieb Tambet Ingo: On 9/29/07, Helmut Schaa [EMAIL PROTECTED] wrote: ActivateDevice would then take the device's object-path and the connection's object-path as arguments, right? Internally, yes, but it will not be exposed over dbus. So, how would the call look like? node name=/ interface name=org.freedesktop.NetworkManager method name=ActivateDevice annotation name=org.freedesktop.DBus.GLib.Async value=/ arg name=device type=o direction=in/ arg name=service_name type=s direction=in/ arg name=connection type=o direction=in/ arg name=specific_object type=o direction=in/ /method /node Note that the call is supposed to be asynchronous: It will not return before it knows the device activation will be started. If the connection referenced by connection object path is not found, NM waits for up to 5 seconds in hope to receive the connection. If the call is made synchronously (from a single threaded app, that is), there is no way NM would be able to update it's known connections from the frontend (which is blocking on waiting for the reply). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wpa_supplicant options
On 9/4/07, Joel Goguen [EMAIL PROTECTED] wrote: Will the options be exposed in a config file later on? Having them hard-coded doesn't allow users much choice if they have even the slightest need to configure wpa_supplicant. In short, no. It's not about users' choice, it's about policy to not support broken wireless drivers that do not (correctly) implement wireless extensions. Some distros (opensuse) have different policies and patch NM to use madwifi wpa_supplicant driver. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Personal experiences (so far) with .7
On 8/14/07, Steev Klimaszewski [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gentoo experiences (which, really, we need to update our backend... I will be working on this soon, I swear) Using r2682, wireless doesn't work at all, the devices show up, however things are greyed out. So it does see the devices. If I pop out a wireless card (I have about 8-10 cards here that I can test the various drivers out) I get the following filling up my log (even if I re-insert the card) Aug 14 15:10:57 sigma NetworkManager: nm_device_get_state: assertion `NM_IS_DEVICE (device)' failed Wired works like a champ though, so that is good, I am just puzzled by why the wireless is greyed out. Even if I don't have a wire plugged in when I start NM, only wireless, it sees the devices, but then nothing. Attempting to create a wireless network or connect to other wireless network also seems to do nothing. Wireless drivers/chipsets tested against: at76c503a (usb) rtl8180 (pcmcia) atheros (0.9.3.2) bcm43xx (in-kernel 2.6.22.3(or .4 whatever is latest) orinoco-sn (http://www.projectiwear.org/~plasmahh/orinoco.html) p54 (usb - in-kernel mac80211) bcm43xx (in-kernel mac80211 as well) ndiswrapper 1.48_rc1 (this is actually a Marvell 88w8335 [Libertas] card, however, pcmcia so not covered by inkernel libertas :( ) mini-pci orinoco card, as well as a mini-pci atheros card - inkernel for the mini-pci orinoco and 0.9.3.1 for the mini-pci atheros card. Any hints? You do have wpa_supplicant = 0.5.7 running as root with -u switch passed to enable dbus interface? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Some fixes for trunk
Hey,
On 8/7/07, Helmut Schaa [EMAIL PROTECTED] wrote:
while porting KNetworkManager to NM 0.7 I found a few issues which need fixing
in NM. Attached are three patches which apply cleanly against trunk.
1) allow_linking_with_cpp.patch:
As the filename indicates this patch adds support for using libnm_util and
libnm_glib from within C++.
I'll replace these with G_BEGIN_DECLS / G_END_DECLS (macros that
expand to exactly the same but will make editors not indent the whole
content of header file because of { }).
2) fix_segfault.patch:
This patch fixes a segfault caused by some ssid being NULL. I don't know if it
is desired to have ssid's being NULL but in current trunk using my ipw2200
I've got a lot of these.
It's NULL for all hidden APs, looks good.
3) fix_memory_corruption.patch
The most important one (it took hours to find the cause). Call to g_object_get
writes a gint (4 byte) into the gint8 output buffer (1 byte) and thus
overwrites some other data (in my case the last_seen property).
Nice catch. The proper fix would be to not write 4 bytes to that
pointer though, I'll commit a fix for that instead.
Please have a look at the patches and commit to trunk.
Thanks! I'll commit all these changes shortly.
Tambet
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Some fixes for trunk
On 8/8/07, Helmut Schaa [EMAIL PROTECTED] wrote: Am Mittwoch, 8. August 2007 12:39:01 schrieb Tambet Ingo: Nice catch. The proper fix would be to not write 4 bytes to that pointer though, I'll commit a fix for that instead. Indeed, but g_object_get is a glib function ;-) ... which calls NetworkManagerAP.c:set_property() for actual assignment. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Some fixes for trunk
On 8/8/07, Helmut Schaa [EMAIL PROTECTED] wrote: Am Mittwoch, 8. August 2007 14:22:10 schrieben Sie: g_object_class_install_property (object_class, PROP_STRENGTH, g_param_spec_int (...)) Exactly ;-) I was at the same point yesterday but could not find a way to specify an int8-property. If that's possible I would like to know about. g_param_spec_char Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Trunk make dist broken missing file?
On 6/26/07, Dan Williams [EMAIL PROTECTED] wrote: On Tue, 2007-06-26 at 14:29 -0500, Steev Klimaszewski wrote: There is no nm-object.h in subversion as far as i can tell, did this file fail to get committed, or is it left out to keep people from testing right now? It might have been, Tambet? Sorry folks, I take the blame. Fixed now, thanks. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Some various thoughts on PPP
Hey, On 5/17/07, Ulrik Mikaelsson [EMAIL PROTECTED] wrote: [snip] Please jump in with your thoughts and ideas. I'm planning to attempt hacking some of this together, but I'd like to get some feedback first, to ensure I'm right on track. Also, if you're hacking on something related, please let me know so we don't waste a lot of good effort. I am working on exactly that. It's been a very long journey since NM was written for wired and wireless devices and adding a new device type (modem) cleanly wasn't really possible (in NM 0.6 branch). After a lot of rework that's gone in to svn trunk, the devices are more abstract, the device activation takes an abstract NMConnection structure for activation info (like IP configuration, wireless security, modem options, ppp options), etc. That's not where the pain ends, it turns out there are no modem dialers that are usable for NM. There actually seem to be only two (at least popular ones), wvdial and chat. wvdial is C++, has a bunch of C++ dependencies and has no way to just dial without starting pppd (which NM will need for general PPP support). chat isn't really a dialer either. Pretty much all the other dialers seem to be just frontends for these two. If anyone knows a dialer that would fit for NM, please let me know, I'd love to throw away what I've come up with so far. That is yet not all, it also turns out HAL doesn't have any notion of modems so the best we can do for now is to get a list of HAL devices with capability serial and try to send some modem initialization strings and see if they respond. That is for the serial devices that actually show up in HAL at all. Most of the thinkpads have a modem that only works with proprietary HSF modem driver and these do not show up in HAL at all. So it all has been surprisingly hard. For this last week I've been working on the actual modem device and ppp interface for NM. The current status is that NM is able to dial out and establish a serial connection that is suitable for ppp. There's a wrapper that turns NM activation structure NMConnection to PPP command line, starts pppd with a special pppd plugin that'll report ppp events (like got IP information, warnings, errors, etc). I'm planning to get all this to svn next week. If you're interested in helping out, I would love to answer any questions you have about it! Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM dialup API
Hey, On 4/19/07, Will Stephenson [EMAIL PROTECTED] wrote: I'm working on the Solid API for network management for KDE 4 and am designing the dialup part now. Since NM is the main backend on KDE's major platform, it influences our API design. There don't seem to be any significant changes regarding dialup in SVN trunk yet, so here's my proposal for an NM dialup API. There's no dialup API in the trunk because there will be none. Just as there's common API for wired and wireless devices, a dialup device will be just another device with exactly the same API and semantics as every other device type. A dialup device is actually very similar to wireless: both need a special setup phase (configuration of the device, connection, and authentication). As a result of dialup device activation, just like of any other device type, is a working network connection. There's no reason to duplicate all the API we currently have for wired and wireless devices (get devices, get device properties, activate, activation stages, etc...) for dialup devices. No reason to confuse the public API consumers and have different NM states for connected using wired or wireless and connected using a dialup device. For configuration (of all device types, including dialup) see http://live.gnome.org/NetworkManagerConfiguration The exact list of setting types is not spec'ed out yet. snip Also, what's the plan regarding the VPN API? Trunk seems mostly the same as 0.6.x. I see parallels between dialup and vpn connections that could be merged, using distinct dbus interfaces for each but with a shared 'ConnectionManager'. The VPN API hasn't changed since NM has been in poor state for long enough and we just haven't had enough resources. The same configuration framework should be used for VPN, and it should have it's own list/properties/status/activate/deactivate interfaces. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dbus-send sleep/wake does not always trigger the action
On 3/30/07, Dawid Wróbel [EMAIL PROTECTED] wrote: Dnia Fri, 30 Mar 2007 08:43:39 + (GMT) yelo_3 [EMAIL PROTECTED] napisał: There is a bug about it. please add your information! http://bugzilla.gnome.org/show_bug.cgi?id=423885 This is something different. It's not that it's just applet that doesn't show correct connection state, it's the whole NM that doesn't suspend/wake - I can see that in the system logs that nothing happens at all. Also, please note that frequent Dispatcher problem. For example now I can clearly see it doesn't work. NM manages to change it's connection status the dispatcher scripts are not executed. Dispatcher is obviously demonized in the background. It will be like this until I restart it. It sounds a lot like some sort of DBUS issue that prevents the messages to reach NM. Is the system bus really busy when it happens? There are some limits in dbus for maximum number of pending calls. Messages that do not fit in that limit are just dropped (AFAIK). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Current SVN broken?
On 3/28/07, Simon Geard [EMAIL PROTECTED] wrote: Ok, I don't think this is the problem I saw last time, but the current failure is that in real_write_supplicant_config(), the call to nm_ap_security_get_key() is returning NULL, causing a segmentation fault on the call to strlen() on line 162. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1212537152 (LWP 27036)] 0xb7c321d3 in strlen () from /lib/libc.so.6 (gdb) bt #0 0xb7c321d3 in strlen () from /lib/libc.so.6 #1 0x08070748 in real_write_supplicant_config (instance=0x809c4c0, config=0x80c1740, adhoc=0) at nm-ap-security-wpa-psk.c:162 #2 0x0805cb25 in real_act_stage2_config (dev=0x80c0088, req=0x80bf7c8) at nm-device-802-11-wireless.c:2705 The reason for the NULL appears to be that nothing has ever called nm_ap_security_set_key(). Is this a consequence of the nm-applet issues you mentioned? I'm not manually doing anything, but I assume the applet is what's telling NM to actually connect to my AP... Interestingly, a message printed out a little earlier indicates it thinks my AP is unencrypted, which is not the case. Could that be relevant? NetworkManager: info Activation (ath0/wireless): access point 'X' is unencrypted, no key needed. Thanks for the info! Update both network-manager-applet and NetworkManager and it should work now. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Current SVN broken?
On 3/27/07, Simon Geard [EMAIL PROTECTED] wrote: Ok, is there any prospect that SVN head might be functional any time soon? Every now and then I try building it, but at best it aborts after start, Can you debug it and see why and where it aborts? It's been working fine for me and Dan for the whole time so it's not going to get magically fixed unless we know what's going on. and right now doesn't build (nm-client.c can't find nm-marshal.h). Sorry, that was my fault, should be fixed now. I'd like to have a go at making the changes I discussed back in January (dealing with non-string SSIDs), but since then I've not managed to get a usable code base to work with. The current SVN trunk should mostly work, except manual activation of wireless devices from nm-applet. If there's info about preferred networks in GConf NM will activate it successfully. VPN also works now. It's still not meant to be used by anyone but developers though, since the configuration work described at http://live.gnome.org/NetworkManagerConfiguration still hasn't been implemented (and that's the reason why activation of wireless devices doesn't work from nm-applet). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: run script after connection is established
On 3/27/07, Dennis Kaarsemaker [EMAIL PROTECTED] wrote: On di, 2007-03-27 at 10:18 -0400, Darren Albers wrote: As Derek Atkins point out NetworkManagerDispatcher does this, there is a script submitted by Matt Good that does something similar for ATT hotspots: http://www.darrenalbers.net/wiki/index.php?title=NetworkManagerScripts Is there a similar thing for VPN connections? Not exactly, but there's a DBUS signal on system bus when VPN state changes. Here's the info: path=/org/freedesktop/NetworkManager/VPNConnections interface=org.freedesktop.NetworkManager.VPNConnections member=VPNConnectionStateChange The signal has two arguments, vpn connection name (string) and connection state (uint32), state == 5 means connected, state == 1 means disconnected. Shouldn't be longer than ~10 lines of python. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: run script after connection is established
On 3/27/07, Dennis Kaarsemaker [EMAIL PROTECTED] wrote: On di, 2007-03-27 at 18:02 +0300, Tambet Ingo wrote: Not exactly, but there's a DBUS signal on system bus when VPN state changes. Here's the info: path=/org/freedesktop/NetworkManager/VPNConnections interface=org.freedesktop.NetworkManager.VPNConnections member=VPNConnectionStateChange The signal has two arguments, vpn connection name (string) and connection state (uint32), state == 5 means connected, state == 1 means disconnected. Shouldn't be longer than ~10 lines of python. Interesting, that signal didn't show up in dbus-monitor... Does for me when I run 'dbus-monitor --system'. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Scannning
Here's how scanning is scheduled: When the nm-applet's devices menu is expanded, NetworkManager schedules a scan to start in 20 seconds. If the menu is deactivated and activated again within that 20 seconds, NM re-schedules the scan after another 20 seconds. So if you keep clicking on applet with intervals less than 20 seconds, the NM initiated scan never happens. When the scan is actually initiated, it takes a bit time to get the results back and it depends on wireless driver how fast/slow it is. If the menu is still expanded, the scan results are not added to the menu, you have to deactivate the menu and activate it again to see the results (and a new scan is scheduled again). There are multiple problems when trying to fix this behavior: * Scanning disables all other operations on card so network doesn't work at that time. That's the reason there is a timeout, that's the reason there can't be a scan now button (well, part of the reason anyway). We need to protect NM from malicious users who can write a shell script to make NM scan constantly (or if they're not smart enough, keep hitting that button/activating the menu manually). [1] * The devices menu is a GtkMenu widget which means the changes made to the menu (adding/removing menu items) while it's expanded doesn't change it's appearance until it's shown next time. Another difficulties are to keep the menu sorted correctly, replace the labels of devices (there's a generic and specific variants, depending on the number of same type devices). Nothing impossible, just requires a lot of work and while the SVN trunk barely works at the moment, it's doesn't make sense to work on that right now. [1] I'm not sure how serious that is since any user can just deactivate all networking anyway. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-applet breakage/fixage
On Wed, 2007-03-14 at 11:46 +0100, Michael Croes wrote: I succesfully compiled NetworkManager revision 2467 and wrote an ebuild that works fine right now. Next problem was network-manager-applet. Now it seems there have been quite some changes in NetworkManager which caused some breakage in network-manager-applet, so it certainly won't compile with minor changes atm. I'd be very happy to (at least try to) fix the current network-manager-applet, but it would be nice if there's some description about the changes in NetworkManager to do so. Is there some place where this is documented in more detail than is done in the svn comments? Or is there someone that can explain the changes to me on irc/mail/msn or anything? You should use the NETWORKMANAGER_0_6_0_RELEASE branch for bleeding edge. The SVN trunk has new DBUS API and doesn't currently work at all with nm-applet. If you want to help out with the development, see NetworkManager/libnm-glib/*.[ch] and replace the DBUS code in nm-applet with libnm-glib code. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-applet release
On Tue, 2007-03-13 at 06:05 -0400, Dan Williams wrote:
I don't think it's really going to work out since the schedules are
somewhat different. There likely won't be a NM 0.6.5 release for
another week or two since there's a crash or two in LEAP support that I
feel need to be nailed before that happens.
I have a patch for one LEAP-related crash.
Tambet
--- src/nm-ap-security-leap.c.orig 2007-02-14 17:20:35.0 +0200
+++ src/nm-ap-security-leap.c 2007-02-14 17:20:24.0 +0200
@@ -152,6 +152,12 @@
return caps;
}
+static gboolean
+real_get_authentication_required (NMAPSecurity *instance)
+{
+ return TRUE;
+}
+
static NMAPSecurity *
real_copy_constructor (NMAPSecurity *instance)
{
@@ -186,6 +192,7 @@
par_class-serialize_func = real_serialize;
par_class-write_supplicant_config_func = real_write_supplicant_config;
par_class-get_default_capabilities_func = real_get_default_capabilities;
+ par_class-get_authentication_required_func = real_get_authentication_required;
g_type_class_add_private (object_class, sizeof (NMAPSecurityLEAPPrivate));
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: settings daemon D-Bus interface proposal
On Mon, 2007-02-26 at 16:44 -0500, Dan Williams wrote: The more I think about it, the more I believe we should stick with my proposal for 0.7 and then move in the direction you've advocated for the next major release. The reason being that we want to do 0.7 fairly quickly, and we don't want to take on more than we've already got. Does that sound OK? Yeah, I agree. We should get 0.7 out as soon as possible. There are simple workarounds for the issues (vpn connections from other users, etc) David pointed out. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: settings daemon D-Bus interface proposal
On Tue, 2007-02-20 at 08:49 -0500, Dan Williams wrote: The system settings service (what we were calling NMI) will run either as 'nobody' or 'root' (I'm not sure yet, thoughts?). Something will have to start it, either NM or the startup scripts. It provides the default/mandatory settings that users have published system-wide or that the sysadmin has set. I'm somewhat afraid that if we run it as 'nobody' that we'll not be able to trust the information we get out of it because it's not root. If we run the system settings service as 'root', then it can access the system-wide published secrets and then NM doesn't have to contain code to read the secrets in some lookaside directory. If it's run as 'nobody' then NM would have to store them. Your thoughts David? It would be very nice if it weren't root. If nobody isn't trusted enough, maybe some other dedicated user, something that could be shared with hal policy daemon etc (which I know nothing about). Would make a lot of security-(paranoid-)people happy. This Gnome system settings daemon will be a copy of nm-applet and will be run with the '--system' argument, which tells the applet to present _no_ UI, not init GTK, and acquire the system settings service name rather than the user-level settings service name. Why do we want to do this? Because of the GConf dependency? In my opinion the settings daemon belongs much more to the core NM than NM-gnome, there's no desktop specific bits in it at all (it doesn't even have any UI or regular user who'd ever log in). I'd suggest using a simple GKeyFile-based configuration mechanism for the daemon for now. There are a lot of people interested in moving GConf down the stack, either below glib or maybe into glib, so it will happen sooner or later. Does this new settings code mean that most of the backends (more precisely, the information reading from /etc/sysconfig part) is now deprecated? If no, which information does the NM prefer, the new daemon or the distro specific? The API itself looks good to me. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Current SVN broken?
On Mon, 2007-02-19 at 21:03 +1300, Simon Geard wrote: Ok, I've given this a couple of weeks for recent changes to settle, but still finding trunk (rev 2337) completely unstable. It takes about 10 seconds to start up, going through the business of reconnecting to the system bus before aborting with the stacktrace. Don't use the SVN head. We know it's completely unstable. We'll let you know when it's usable again. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Errors running current SVN code
On Wed, 2007-01-31 at 10:07 -0500, Dan Williams wrote: Note also that devices themselves are assigned a UID, because if you change 'eth0' to something else on the fly (interface renaming is obviously allowed) then NM shouldn't break here either. Having human readable names was somewhat more compelling in the early days of D-Bus when there weren't as good API, tools, and documentation. But that day is long past. Why not use HAL UDI for device names to get at least some sort of human-readable names? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Errors running current SVN code
On Tue, 2007-02-06 at 07:43 -0500, Dan Williams wrote: We could provide mapping functions, but this is mostly for the D-Bus object paths for objects. HAL UDIs have / in them, which are object paths. I'm not sure using HAL UDIs as our device object paths instead would be clearer, or more confusing, not to mention violating the object path naming scheme :) I don't really think that having a readable object path is that interesting here though, since you have to call other functions (getProperties, etc) to do anything useful with it. HAL uses UDIs for dbus object paths, so it doesn't violate the naming scheme. Both HAL udi and NM device represent the exact same device, why should their names be different? I would also remove all the properties from NMDevice DBUS interface that already exist in HAL DBUS interface, so NMDevices would be sort of inherited from HAL devices (or just implement a different interface for the _same_ device). It would make NM be part of a bigger picture rather than being a standalone app. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[Patch] Mark devices disabled on suse
Hey,
Here's a small patch to mark devices disabled when they're disabled in
yast.
Tambet
Index: ChangeLog
===
RCS file: /cvs/gnome/NetworkManager/ChangeLog,v
retrieving revision 1.866.2.140
diff -u -r1.866.2.140 ChangeLog
--- ChangeLog 27 Nov 2006 21:38:07 - 1.866.2.140
+++ ChangeLog 30 Nov 2006 09:44:58 -
@@ -1,3 +1,8 @@
+2006-11-30 Tambet Ingo [EMAIL PROTECTED]
+
+ * src/backends/NetworkManagerSuSE.c (nm_system_device_get_system_config):
+ Mark device as disabled when the STARTMODE variable is either 'off' or 'manual'.
+
2006-11-27 Dan Williams [EMAIL PROTECTED]
Patch from Christian Persch [EMAIL PROTECTED]
Index: src/backends/NetworkManagerSuSE.c
===
RCS file: /cvs/gnome/NetworkManager/src/backends/NetworkManagerSuSE.c,v
retrieving revision 1.32.2.25
diff -u -r1.32.2.25 NetworkManagerSuSE.c
--- src/backends/NetworkManagerSuSE.c 8 Nov 2006 09:20:55 - 1.32.2.25
+++ src/backends/NetworkManagerSuSE.c 30 Nov 2006 09:44:58 -
@@ -518,6 +518,17 @@
free (buf);
}
+ if ((buf = svGetValue (file, STARTMODE)))
+ {
+ nm_debug (STARTMODE=%s, buf);
+ if (!strcasecmp (buf, off) || !strcasecmp (buf, manual))
+ {
+ nm_info (System configuration disables device %s, nm_device_get_iface (dev));
+ sys_data-system_disabled = TRUE;
+ }
+ free (buf);
+ }
+
if ((buf = svGetValue (file, MTU)))
{
guint32 mtu;
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[Patch] Validate input in vpnc importer
Here's a patch to check if the pcf file values contain non-utf8
characters and tries quite hard to produce valid utf8 from it. First,
using the current locale and ISO-8859-15 (usable for majority of western
european languages) if that fails.
Tambet
? nm-vpnc-pcf-import-utf8.diff
? po/cs.gmo
? po/de.gmo
? po/es.gmo
? po/fi.gmo
? po/fr.gmo
? po/hu.gmo
? po/it.gmo
? po/ja.gmo
? po/pl.gmo
? po/pt_BR.gmo
? po/zh_CN.gmo
? po/zh_TW.gmo
Index: properties/pcf-file.c
===
RCS file: /cvs/gnome/NetworkManager/vpn-daemons/vpnc/properties/pcf-file.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 pcf-file.c
--- properties/pcf-file.c 1 Nov 2006 16:33:28 - 1.1.2.1
+++ properties/pcf-file.c 13 Nov 2006 11:12:09 -
@@ -15,6 +15,32 @@
}
}
+/* Stolen from gaim */
+
+static char *
+pcf_utf8_try_convert (const char *str)
+{
+ char *utf8;
+ gsize converted;
+
+ if (!str)
+ return NULL;
+
+ if (g_utf8_validate (str, -1, NULL))
+ return g_strdup (str);
+
+ utf8 = g_locale_to_utf8 (str, -1, NULL, NULL, NULL);
+ if (utf8)
+ return utf8;
+
+ utf8 = g_convert (str, -1, UTF-8, ISO-8859-15, converted, NULL, NULL);
+ if (utf8 converted == strlen (str))
+ return utf8;
+
+ g_free (utf8);
+ return NULL;
+}
+
/*
The main reader loop here is based on the simple .ini file
parser from avahi/avahi-daemon/ini-file-parser.c
@@ -87,7 +113,7 @@
*(e++) = 0;
entry = g_new (PcfEntry, 1);
- entry-value = g_strdup (e);
+ entry-value = pcf_utf8_try_convert (e);
if (*s == '!') {
entry-key = g_utf8_strdown (s+1, -1);
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[Patch] Some more leaks and memory corruptions
Hey,
Here's a quite long patch for 0.6 branch. In addition to fixes to simple
leaks which don't need any explanation, I'll try to comment the bigger
changes and why I did them.
NetworkManager.c (nm_data_free):
I added a comment there why it's necessary, but in short, removing all
devices most likely triggers a state change, which gets scheduled, but
never has a chance to run. It wouldn't be a big deal, but the scheduled
signal emitters have references to devices which prevents them getting
cleaned properly. Also, since these signals now actually do run, the
order of clean up needed some changes.
nm-dbus-nmi.c:
vpn-manager/nm-dbus-vpn.c
Remove 'dbus_pending_call_ref (pcall)' calls from dbus callbacks - we
already own them, it just leaks all the pcalls.
NetworkManagerPolicy.c:
nm-device.c
For all the scheduled functions which pass NMActRequest, increment the
reference count when scheduling and release the reference in callback.
This is mostly needed to avoid problems when activation is canceled (or
fails) at unfortunate moments and the NMActRequest gets freed before the
callback has a chance to run.
nm-device-802-11-wireless.c:
There was some unusual reference counting patterns there: in some cases,
when a callback is scheduled (g_source_attach), the reference count of
the source was balanced at the callback - which works fine if the
callback actually has the chance to run. Removing a device frees it's
GMainContext, leaving all scheduled callbacks (and their user_data!)
alive. So to fix that, the reference of the source is given to
GMainContext, so when it exits, it can cleanly free the sources. Also,
instead of freeing callback' user_data in callback, use the
GDestroyNotify of the source to free them - again, so the the
GMainContext can clean things up without calling the callback.
Tambet
? nm-leaks.diff
Index: NetworkManager.c
===
RCS file: /cvs/gnome/NetworkManager/src/NetworkManager.c,v
retrieving revision 1.104.2.7
diff -u -r1.104.2.7 NetworkManager.c
--- NetworkManager.c 3 Nov 2006 11:39:15 - 1.104.2.7
+++ NetworkManager.c 7 Nov 2006 13:14:34 -
@@ -485,8 +485,8 @@
{
g_return_if_fail (dev != NULL);
- nm_device_set_removed (dev, TRUE);
- nm_device_deactivate (dev);
+ nm_device_set_removed (dev, TRUE);
+ nm_device_stop (dev);
g_object_unref (G_OBJECT (dev));
}
@@ -507,20 +507,28 @@
if ((req = nm_vpn_manager_get_vpn_act_request (data-vpn_manager)))
nm_vpn_manager_deactivate_vpn_connection (data-vpn_manager, nm_vpn_act_request_get_parent_dev (req));
- if (data-netlink_monitor)
- {
- g_object_unref (G_OBJECT (data-netlink_monitor));
- data-netlink_monitor = NULL;
- }
-
/* Stop and destroy all devices */
nm_lock_mutex (data-dev_list_mutex, __FUNCTION__);
g_slist_foreach (data-dev_list, (GFunc) device_stop_and_free, NULL);
g_slist_free (data-dev_list);
+ data-dev_list = NULL;
nm_unlock_mutex (data-dev_list_mutex, __FUNCTION__);
+ /* device_stop_and_free() deactivates devices, which triggers state change
+ signals. Without cleaning the queue, they never get the chance to fire,
+ keeping the device references alive.
+ */
+ while (g_main_context_pending (data-main_context))
+ g_main_context_iteration (data-main_context, TRUE);
+
g_mutex_free (data-dev_list_mutex);
+ if (data-netlink_monitor)
+ {
+ g_object_unref (G_OBJECT (data-netlink_monitor));
+ data-netlink_monitor = NULL;
+ }
+
nm_ap_list_unref (data-allowed_ap_list);
nm_ap_list_unref (data-invalid_ap_list);
@@ -536,7 +544,7 @@
nm_dbus_method_list_free (data-net_methods);
nm_dbus_method_list_free (data-vpn_methods);
- g_io_channel_unref(data-sigterm_iochannel);
+ g_io_channel_unref (data-sigterm_iochannel);
nm_hal_deinit (data);
Index: NetworkManagerAP.c
===
RCS file: /cvs/gnome/NetworkManager/src/NetworkManagerAP.c,v
retrieving revision 1.53.2.4
diff -u -r1.53.2.4 NetworkManagerAP.c
--- NetworkManagerAP.c 21 Oct 2006 03:41:19 - 1.53.2.4
+++ NetworkManagerAP.c 7 Nov 2006 13:14:34 -
@@ -537,6 +537,7 @@
/* Free existing list */
g_slist_foreach (ap-user_addresses, (GFunc) g_free, NULL);
+ g_slist_free (ap-user_addresses);
/* Copy new list and set as our own */
for (elt = list; elt; elt = g_slist_next (elt))
Index: NetworkManagerDbus.c
===
RCS file: /cvs/gnome/NetworkManager/src/NetworkManagerDbus.c,v
retrieving revision 1.106.2.3
diff -u -r1.106.2.3 NetworkManagerDbus.c
--- NetworkManagerDbus.c 21 May 2006 17:28:02 - 1.106.2.3
+++ NetworkManagerDbus.c 7 Nov 2006 13:14:34 -
@@ -207,9 +207,9 @@
static gboolean nm_dbus_signal_device_status_change (gpointer user_data)
{
NMStatusChangeData *cb_data = (NMStatusChangeData *)user_data;
- DBusMessage * message;
- char * dev_path;
- const char * sig = NULL;
+ DBusMessage * message = NULL;
+ char * dev_path = NULL;
[Patch] some nm-applet leak fixes
Hey,
as the subject says...
Tambet
? applet-leaks.diff
Index: applet/nm-device.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/nm-device.c,v
retrieving revision 1.17.2.1
diff -u -r1.17.2.1 nm-device.c
--- applet/nm-device.c 25 May 2006 20:12:25 - 1.17.2.1
+++ applet/nm-device.c 7 Nov 2006 17:01:06 -
@@ -164,6 +164,8 @@
g_free (dev-broadcast);
g_free (dev-netmask);
g_free (dev-ip4addr);
+ g_free (dev-primary_dns);
+ g_free (dev-secondary_dns);
memset (dev, 0, sizeof (NetworkDevice));
g_free (dev);
}
Index: applet/passphrase-dialog.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/passphrase-dialog.c,v
retrieving revision 1.26.2.2
diff -u -r1.26.2.2 passphrase-dialog.c
--- applet/passphrase-dialog.c 24 May 2006 15:52:45 - 1.26.2.2
+++ applet/passphrase-dialog.c 7 Nov 2006 17:01:06 -
@@ -86,6 +86,7 @@
GtkWidget * wso_widget;
GladeXML * xml;
GtkWidget * vbox;
+ GList * children;
GList * elt;
g_return_if_fail (dialog != NULL);
@@ -98,13 +99,16 @@
vbox = GTK_WIDGET (glade_xml_get_widget (xml, wireless_security_vbox));
/* Remove any previous wireless security widgets */
- for (elt = gtk_container_get_children (GTK_CONTAINER (vbox)); elt; elt = g_list_next (elt))
+ children = gtk_container_get_children (GTK_CONTAINER (vbox));
+ for (elt = children; elt; elt = g_list_next (elt))
{
GtkWidget * child = GTK_WIDGET (elt-data);
if (wso_is_wso_widget (child))
gtk_container_remove (GTK_CONTAINER (vbox), child);
}
+
+ g_list_free (children);
/* Determine and add the correct wireless security widget to the dialog */
wso_widget = wsm_get_widget_for_active (wsm, GTK_COMBO_BOX (security_combo), GTK_SIGNAL_FUNC (update_button_cb), dialog);
Index: applet/vpn-password-dialog.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/vpn-password-dialog.c,v
retrieving revision 1.8.2.1
diff -u -r1.8.2.1 vpn-password-dialog.c
--- applet/vpn-password-dialog.c 24 May 2006 15:52:45 - 1.8.2.1
+++ applet/vpn-password-dialog.c 7 Nov 2006 17:01:06 -
@@ -53,7 +53,7 @@
static gboolean
child_stdout_data_cb (GIOChannel *source, GIOCondition condition, gpointer userdata)
{
- char *str;
+ char *str = NULL;
IOUserData *io_user_data = (IOUserData *) userdata;
GSList **passwords = (GSList **) io_user_data-passwords;
@@ -77,10 +77,13 @@
/* remove terminating newline */
str[len - 1] = '\0';
*passwords = g_slist_append (*passwords, str);
+ str = NULL;
}
}
out:
+ g_free (str);
+
return TRUE;
}
Index: applet/wireless-security-manager.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/wireless-security-manager.c,v
retrieving revision 1.15.2.1
diff -u -r1.15.2.1 wireless-security-manager.c
--- applet/wireless-security-manager.c 21 Oct 2006 03:41:18 - 1.15.2.1
+++ applet/wireless-security-manager.c 7 Nov 2006 17:01:06 -
@@ -162,14 +162,13 @@
WirelessSecurityOption * opt = NULL;
GtkTreeIter iter;
GtkTreeModel * model;
- char *str;
g_return_val_if_fail (combo != NULL, NULL);
model = gtk_combo_box_get_model (combo);
g_assert (model);
if (gtk_combo_box_get_active_iter (combo, iter))
- gtk_tree_model_get (model, iter, NAME_COLUMN, str, OPT_COLUMN, opt, -1);
+ gtk_tree_model_get (model, iter, OPT_COLUMN, opt, -1);
return opt;
}
@@ -215,6 +214,7 @@
{
g_return_if_fail (wsm != NULL);
+ g_free (wsm-glade_file);
g_slist_foreach (wsm-options, (GFunc) wso_free, NULL);
g_slist_free (wsm-options);
memset (wsm, 0, sizeof (WirelessSecurityManager));
Index: applet/wireless-security-option.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/wireless-security-option.c,v
retrieving revision 1.10.2.2
diff -u -r1.10.2.2 wireless-security-option.c
--- applet/wireless-security-option.c 22 Mar 2006 21:26:57 - 1.10.2.2
+++ applet/wireless-security-option.c 7 Nov 2006 17:01:06 -
@@ -170,14 +170,13 @@
GtkTreeIter iter;
GtkTreeModel * model;
int auth_alg;
- char * str;
g_return_val_if_fail (opt != NULL, -1);
g_return_val_if_fail (combo != NULL, -1);
model = gtk_combo_box_get_model (combo);
gtk_combo_box_get_active_iter (GTK_COMBO_BOX (combo), iter);
- gtk_tree_model_get (model, iter, NAME_COLUMN, str, AUTH_ALG_COLUMN, auth_alg, -1);
+ gtk_tree_model_get (model, iter, AUTH_ALG_COLUMN, auth_alg, -1);
return auth_alg;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[Patch] Fix a bunch of leaks
Hey,
Just as the subject says, fix about 10 memory leaks.
Tambet
Index: gnome/applet/applet.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet.c,v
retrieving revision 1.112.2.12
diff -u -r1.112.2.12 applet.c
--- gnome/applet/applet.c 25 Oct 2006 03:39:20 - 1.112.2.12
+++ gnome/applet/applet.c 2 Nov 2006 15:23:09 -
@@ -1764,12 +1764,14 @@
label = g_strdup_printf (_(Connect to %s...), name);
connect_item = GTK_MENU_ITEM (gtk_menu_item_new_with_label (label));
+ g_free (label);
g_object_set_data (G_OBJECT (connect_item), dialup, name);
g_signal_connect (G_OBJECT (connect_item), activate, G_CALLBACK (nma_menu_dialup_connect_item_activate), applet);
gtk_menu_shell_append (GTK_MENU_SHELL (dialup_menu), GTK_WIDGET (connect_item));
label = g_strdup_printf (_(Disconnect from %s...), name);
disconnect_item = GTK_MENU_ITEM (gtk_menu_item_new_with_label (label));
+ g_free (label);
g_object_set_data (G_OBJECT (disconnect_item), dialup, name);
g_signal_connect (G_OBJECT (disconnect_item), activate, G_CALLBACK (nma_menu_dialup_disconnect_item_activate), applet);
gtk_menu_shell_append (GTK_MENU_SHELL (dialup_menu), GTK_WIDGET (disconnect_item));
Index: gnome/applet/menu-items.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/menu-items.c,v
retrieving revision 1.12.2.1
diff -u -r1.12.2.1 menu-items.c
--- gnome/applet/menu-items.c 17 May 2006 20:03:56 - 1.12.2.1
+++ gnome/applet/menu-items.c 2 Nov 2006 15:23:09 -
@@ -91,6 +91,7 @@
text = g_strdup (_(_Wired Network));
gtk_label_set_text_with_mnemonic (GTK_LABEL (item-label), text);
+ g_free (text);
/* Only dim the item if the device supports carrier detection AND
* we know it doesn't have a link.
Index: src/nm-dbus-device.c
===
RCS file: /cvs/gnome/NetworkManager/src/nm-dbus-device.c,v
retrieving revision 1.27.2.1
diff -u -r1.27.2.1 nm-dbus-device.c
--- src/nm-dbus-device.c 21 Jun 2006 14:33:35 - 1.27.2.1
+++ src/nm-dbus-device.c 2 Nov 2006 15:23:09 -
@@ -489,6 +489,8 @@
g_free (ip4_address);
g_free (broadcast);
g_free (subnetmask);
+ g_free (primary_dns);
+ g_free (secondary_dns);
}
return reply;
Index: src/nm-device.c
===
RCS file: /cvs/gnome/NetworkManager/src/nm-device.c,v
retrieving revision 1.17.2.7
diff -u -r1.17.2.7 nm-device.c
--- src/nm-device.c 20 Sep 2006 15:35:12 - 1.17.2.7
+++ src/nm-device.c 2 Nov 2006 15:23:10 -
@@ -85,14 +85,22 @@
discover_device_type (LibHalContext *ctx, const char *udi)
{
char * category = NULL;
+ NMDeviceType type = DEVICE_TYPE_UNKNOWN;
if (libhal_device_property_exists (ctx, udi, info.category, NULL))
category = libhal_device_get_property_string(ctx, udi, info.category, NULL);
- if (category (!strcmp (category, net.80211)))
- return DEVICE_TYPE_802_11_WIRELESS;
- else if (category (!strcmp (category, net.80203)))
- return DEVICE_TYPE_802_3_ETHERNET;
- return DEVICE_TYPE_UNKNOWN;
+
+ if (category)
+ {
+ if (!strcmp (category, net.80211))
+ type = DEVICE_TYPE_802_11_WIRELESS;
+ else if (!strcmp (category, net.80203))
+ type = DEVICE_TYPE_802_3_ETHERNET;
+
+ libhal_free_string (category);
+ }
+
+ return type;
}
/*
Index: src/backends/NetworkManagerSuSE.c
===
RCS file: /cvs/gnome/NetworkManager/src/backends/NetworkManagerSuSE.c,v
retrieving revision 1.32.2.23
diff -u -r1.32.2.23 NetworkManagerSuSE.c
--- src/backends/NetworkManagerSuSE.c 19 Oct 2006 20:39:54 - 1.32.2.23
+++ src/backends/NetworkManagerSuSE.c 2 Nov 2006 15:23:10 -
@@ -808,6 +808,8 @@
if (sys_data-config)
nm_ip4_config_unref (sys_data-config);
+
+ g_free (sys_data);
}
Index: src/backends/shvar.c
===
RCS file: /cvs/gnome/NetworkManager/src/backends/shvar.c,v
retrieving revision 1.2
diff -u -r1.2 shvar.c
--- src/backends/shvar.c 6 May 2005 21:20:42 - 1.2
+++ src/backends/shvar.c 2 Nov 2006 15:23:10 -
@@ -392,7 +392,12 @@
}
g_free(s-fileName);
g_list_free(s-freeList);
-g_list_free(s-lineList); /* implicitly frees s-current */
+
+ if (s-lineList) {
+ g_list_foreach(s-lineList, (GFunc) g_free, NULL);
+ g_list_free(s-lineList); /* implicitly frees s-current */
+ }
+
g_free(s);
return 0;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [Patch] Fix a bunch of leaks
Here's a diff that includes fixes to another couple of leaks.
Tambet
On Thu, 2006-11-02 at 17:23 +0200, Tambet Ingo wrote:
Hey,
Just as the subject says, fix about 10 memory leaks.
Tambet
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Index: gnome/applet/applet.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet.c,v
retrieving revision 1.112.2.12
diff -u -r1.112.2.12 applet.c
--- gnome/applet/applet.c 25 Oct 2006 03:39:20 - 1.112.2.12
+++ gnome/applet/applet.c 2 Nov 2006 16:01:10 -
@@ -1764,12 +1764,14 @@
label = g_strdup_printf (_(Connect to %s...), name);
connect_item = GTK_MENU_ITEM (gtk_menu_item_new_with_label (label));
+ g_free (label);
g_object_set_data (G_OBJECT (connect_item), dialup, name);
g_signal_connect (G_OBJECT (connect_item), activate, G_CALLBACK (nma_menu_dialup_connect_item_activate), applet);
gtk_menu_shell_append (GTK_MENU_SHELL (dialup_menu), GTK_WIDGET (connect_item));
label = g_strdup_printf (_(Disconnect from %s...), name);
disconnect_item = GTK_MENU_ITEM (gtk_menu_item_new_with_label (label));
+ g_free (label);
g_object_set_data (G_OBJECT (disconnect_item), dialup, name);
g_signal_connect (G_OBJECT (disconnect_item), activate, G_CALLBACK (nma_menu_dialup_disconnect_item_activate), applet);
gtk_menu_shell_append (GTK_MENU_SHELL (dialup_menu), GTK_WIDGET (disconnect_item));
Index: gnome/applet/menu-items.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/menu-items.c,v
retrieving revision 1.12.2.1
diff -u -r1.12.2.1 menu-items.c
--- gnome/applet/menu-items.c 17 May 2006 20:03:56 - 1.12.2.1
+++ gnome/applet/menu-items.c 2 Nov 2006 16:01:10 -
@@ -91,6 +91,7 @@
text = g_strdup (_(_Wired Network));
gtk_label_set_text_with_mnemonic (GTK_LABEL (item-label), text);
+ g_free (text);
/* Only dim the item if the device supports carrier detection AND
* we know it doesn't have a link.
Index: src/NetworkManager.c
===
RCS file: /cvs/gnome/NetworkManager/src/NetworkManager.c,v
retrieving revision 1.104.2.5
diff -u -r1.104.2.5 NetworkManager.c
--- src/NetworkManager.c 20 Sep 2006 15:35:12 - 1.104.2.5
+++ src/NetworkManager.c 2 Nov 2006 16:01:10 -
@@ -531,6 +531,11 @@
g_main_loop_unref (data-main_loop);
g_main_context_unref (data-main_context);
+ nm_dbus_method_list_free (data-nm_methods);
+ nm_dbus_method_list_free (data-device_methods);
+ nm_dbus_method_list_free (data-net_methods);
+ nm_dbus_method_list_free (data-vpn_ethods);
+
g_io_channel_unref(data-sigterm_iochannel);
nm_hal_deinit (data);
Index: src/nm-dbus-device.c
===
RCS file: /cvs/gnome/NetworkManager/src/nm-dbus-device.c,v
retrieving revision 1.27.2.1
diff -u -r1.27.2.1 nm-dbus-device.c
--- src/nm-dbus-device.c 21 Jun 2006 14:33:35 - 1.27.2.1
+++ src/nm-dbus-device.c 2 Nov 2006 16:01:10 -
@@ -489,6 +489,8 @@
g_free (ip4_address);
g_free (broadcast);
g_free (subnetmask);
+ g_free (primary_dns);
+ g_free (secondary_dns);
}
return reply;
Index: src/nm-device.c
===
RCS file: /cvs/gnome/NetworkManager/src/nm-device.c,v
retrieving revision 1.17.2.7
diff -u -r1.17.2.7 nm-device.c
--- src/nm-device.c 20 Sep 2006 15:35:12 - 1.17.2.7
+++ src/nm-device.c 2 Nov 2006 16:01:11 -
@@ -85,14 +85,22 @@
discover_device_type (LibHalContext *ctx, const char *udi)
{
char * category = NULL;
+ NMDeviceType type = DEVICE_TYPE_UNKNOWN;
if (libhal_device_property_exists (ctx, udi, info.category, NULL))
category = libhal_device_get_property_string(ctx, udi, info.category, NULL);
- if (category (!strcmp (category, net.80211)))
- return DEVICE_TYPE_802_11_WIRELESS;
- else if (category (!strcmp (category, net.80203)))
- return DEVICE_TYPE_802_3_ETHERNET;
- return DEVICE_TYPE_UNKNOWN;
+
+ if (category)
+ {
+ if (!strcmp (category, net.80211))
+ type = DEVICE_TYPE_802_11_WIRELESS;
+ else if (!strcmp (category, net.80203))
+ type = DEVICE_TYPE_802_3_ETHERNET;
+
+ libhal_free_string (category);
+ }
+
+ return type;
}
/*
Index: src/backends/NetworkManagerSuSE.c
===
RCS file: /cvs/gnome/NetworkManager/src/backends/NetworkManagerSuSE.c,v
retrieving revision 1.32.2.23
diff -u -r1.32.2.23 NetworkManagerSuSE.c
--- src/backends/NetworkManagerSuSE.c 19 Oct 2006 20:39:54 - 1.32.2.23
+++ src/backends/NetworkManagerSuSE.c 2 Nov 2006 16:01:11 -
@@ -808,6 +808,8 @@
if (sys_data-config)
nm_ip4_config_unref (sys_data-config);
+
+ g_free (sys_data);
}
Index: src/backends/shvar.c
[Patch] Make vpnc file importing a bit nicer
Hey,
There are some issues with importing .pcf files. First, we're trying to
parse them with GKeyFile which is a bit different from pcf files: The
character for comments is '#' (instead of ';'), section names and key
names are case sensitive (instead of ... well, case insensitive).
The .pcf file also has a format !key which means 'key' and it's not
changeable by user instead of literal !key key.
So here's a patch to implement a simple parser for pcf files.
Additionally, this patch makes the importer use same rules as the UI for
required keys (for example, there's no reason a .pcf file must contain
key 'NTDomain'). As a bonus, it also fixes a memory leak (loaded routes
were never freed).
Tambet
Index: properties/Makefile.am
===
RCS file: /cvs/gnome/NetworkManager/vpn-daemons/vpnc/properties/Makefile.am,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 Makefile.am
--- properties/Makefile.am 27 Sep 2006 15:10:31 - 1.1.2.2
+++ properties/Makefile.am 25 Oct 2006 13:31:54 -
@@ -3,6 +3,8 @@
lib_LTLIBRARIES = libnm-vpnc-properties.la
libnm_vpnc_properties_la_SOURCES = \
+pcf-file.c \
+pcf-file.h \
nm-vpnc.c
gladedir = $(datadir)/gnome-vpn-properties/vpnc
Index: properties/nm-vpnc.c
===
RCS file: /cvs/gnome/NetworkManager/vpn-daemons/vpnc/properties/nm-vpnc.c,v
retrieving revision 1.5.2.2
diff -u -r1.5.2.2 nm-vpnc.c
--- properties/nm-vpnc.c 27 Sep 2006 15:10:32 - 1.5.2.2
+++ properties/nm-vpnc.c 25 Oct 2006 13:31:54 -
@@ -32,6 +32,7 @@
#define NM_VPN_API_SUBJECT_TO_CHANGE
#include nm-vpn-ui-interface.h
+#include pcf-file.h
typedef struct _NetworkManagerVpnUIImpl NetworkManagerVpnUIImpl;
@@ -478,95 +479,85 @@
static gboolean
import_from_file (NetworkManagerVpnUIImpl *impl, const char *path)
{
- char *basename;
- GKeyFile *keyfile;
- gboolean file_is_good;
-
- /*printf (path='%s'\n, path);*/
-
- file_is_good = FALSE;
- basename = g_path_get_basename (path);
-
- keyfile = g_key_file_new ();
- if (g_key_file_load_from_file (keyfile, path, 0, NULL)) {
- char *connectionname = NULL;
- char *gateway = NULL;
- char *groupname = NULL;
- char *username = NULL;
- char *domain = NULL;
- char *tunneling_mode = NULL;
- char *routes = NULL;
- gboolean should_expand;
-
- if ((connectionname = g_key_file_get_string (keyfile, main, Description, NULL)) == NULL)
- goto error;
- if ((gateway = g_key_file_get_string (keyfile, main, Host, NULL)) == NULL)
- goto error;
- if ((groupname = g_key_file_get_string (keyfile, main, GroupName, NULL)) == NULL)
- goto error;
- if ((username = g_key_file_get_string (keyfile, main, Username, NULL)) == NULL)
- goto error;
- if ((domain = g_key_file_get_string (keyfile, main, NTDomain, NULL)) == NULL)
- goto error;
- if ((tunneling_mode = g_key_file_get_string (keyfile, main, TunnelingMode, NULL)) == NULL)
- goto error;
-
- /* may not exist */
- if ((routes = g_key_file_get_string (keyfile, main, X-NM-Routes, NULL)) == NULL)
- routes = g_strdup ();
-
- /* sanity check data */
- if (! (strlen (gateway) 0
- strlen (groupname) 0))
- goto error;
-
- gtk_entry_set_text (impl-w_connection_name, connectionname);
- gtk_entry_set_text (impl-w_gateway, gateway);
- gtk_entry_set_text (impl-w_group_name, groupname);
-
- gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (impl-w_use_alternate_username), strlen (username) 0);
- gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (impl-w_use_routes), strlen (routes) 0);
- gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (impl-w_use_domain), strlen (domain) 0);
- gtk_entry_set_text (impl-w_username, username);
- gtk_entry_set_text (impl-w_routes, routes);
- gtk_entry_set_text (impl-w_domain, domain);
- gtk_widget_set_sensitive (GTK_WIDGET (impl-w_username), strlen (username) 0);
- gtk_widget_set_sensitive (GTK_WIDGET (impl-w_routes), strlen (routes) 0);
- gtk_widget_set_sensitive (GTK_WIDGET (impl-w_domain), strlen (username) 0);
+ GHashTable *pcf;
+ const char *buf;
+ gboolean have_value;
+ char *basename = NULL;
+ gboolean expand = FALSE;
+ gboolean success = FALSE;
+
+ pcf = pcf_file_load (path);
+ if (pcf == NULL)
+ return FALSE;
+
+ /* Connection name */
+ if ((buf = pcf_file_lookup_value (pcf, main, Description)) == NULL || strlen (buf) 1)
+ goto error;
+ gtk_entry_set_text (impl-w_connection_name, buf);
+
+ /* Gateway */
+ if ((buf = pcf_file_lookup_value (pcf, main, Host)) == NULL || strlen (buf) 1)
+ goto error;
+ gtk_entry_set_text (impl-w_gateway, buf);
+
+ /* Group name */
+ if ((buf = pcf_file_lookup_value (pcf, main, GroupName)) == NULL || strlen (buf) 1)
+ goto error;
+ gtk_entry_set_text (impl-w_group_name, buf);
+
+ /* Optional settings */
+
+ if ((buf = pcf_file_lookup_value (pcf, main, UserName)))
+ gtk_entry_set_text (impl-w_username, buf);
+ have_value = buf == NULL ? FALSE : strlen (buf) 0;
+ expand |=
Re: [Patch] Make vpnc file importing a bit nicer
On Wed, 2006-10-25 at 12:02 -0400, Dan Williams wrote: Is this targetted for HEAD, stable, or both? Both. Looks good from a quick check, feel free to commit to HEAD at least. I'll take a longer look if you want to commit to stable too, just let me know. Please do. Thanks, Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[Patch] build prefix fixes
Hey,
The attached patch makes nm-applet search it's icons from the installed
prefix.
Tambet
Index: gnome/applet/Makefile.am
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/Makefile.am,v
retrieving revision 1.23
diff -u -r1.23 Makefile.am
--- gnome/applet/Makefile.am 13 Jul 2006 17:03:29 - 1.23
+++ gnome/applet/Makefile.am 10 Oct 2006 12:40:42 -
@@ -17,7 +17,7 @@
$(LIBGNOMEUI_CFLAGS)\
$(PANEL_APPLET_CFLAGS)\
$(GNOME_KEYRING_CFLAGS)\
- -DICONDIR=\$(datadir)/pixmaps\ \
+ -DICONDIR=\$(datadir)/icons\ \
-DGLADEDIR=\$(gladedir)\ \
-DBINDIR=\$(bindir)\\
-DSYSCONFDIR=\$(sysconfdir)\ \
Index: gnome/applet/applet.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet.c,v
retrieving revision 1.123
diff -u -r1.123 applet.c
--- gnome/applet/applet.c 9 Jul 2006 23:37:40 - 1.123
+++ gnome/applet/applet.c 10 Oct 2006 12:40:43 -
@@ -144,6 +144,9 @@
{
GObjectClass *gobject_class;
+ gtk_icon_theme_append_search_path (gtk_icon_theme_get_default (),
+ICONDIR);
+
gobject_class = G_OBJECT_CLASS (klass);
gobject_class-constructor = nma_constructor;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[Patch] Some fixes for SoC branch
Hey,
here's a patch for SoC branch - to make it to compile and more-or-less
working. I say more-or-less because it at least compiles now, the
dialogs for add/edit/remove ppp connections seem to work, and when
trying to activate a ppp connection, it seems to do something. Not sure
if the right thing, as I don't have a modem right now.
In addition to the attached patch, I'm proposing to add new files (also
attached) and remove dialup-services/Makefile from CVS.
Tambet
as-ac-expand.m4
Description: application/m4
nmbtgprsservicedir = $(sysconfdir)/NetworkManager/dialup
nmbtgprsservice_DATA = nm-btgprs-service.name
nmmodemservicedir = $(sysconfdir)/NetworkManager/dialup
nmmodemservice_DATA = nm-modem-service.name
nmpppoeservicedir = $(sysconfdir)/NetworkManager/dialup
nmpppoeservice_DATA = nm-pppoe-service.name
EXTRA_DIST = $(nmbtgprsservice_DATA) \
$(nmmodemservice_DATA) \
$(nmpppoeservice_DATA)
CLEANFILES = *~
Index: autogen.sh
===
RCS file: /cvs/gnome/NetworkManager/autogen.sh,v
retrieving revision 1.4
diff -u -r1.4 autogen.sh
--- autogen.sh 21 Oct 2004 18:22:25 - 1.4
+++ autogen.sh 10 Oct 2006 16:25:31 -
@@ -13,6 +13,7 @@
exit 1
}
+ACLOCAL_FLAGS=-I . $ACLOCAL_FLAGS
which gnome-autogen.sh || {
echo You need to install gnome-common from the GNOME CVS
Index: configure.in
===
RCS file: /cvs/gnome/NetworkManager/configure.in,v
retrieving revision 1.138.2.3
diff -u -r1.138.2.3 configure.in
--- configure.in 25 Aug 2006 11:35:52 - 1.138.2.3
+++ configure.in 10 Oct 2006 16:25:31 -
@@ -278,36 +278,17 @@
AC_DEFINE_UNQUOTED(IP_BINARY_PATH, $IP_BINARY_PATH, [Define to path of ip binary])
AC_SUBST(IP_BINARY_PATH)
- find the actual value for $prefix that we'll end up with
-## (I know this is broken and should be done in the Makefile, but
-##that's a major pain and almost nobody actually seems to care)
-REAL_PREFIX=
-if test x$prefix = xNONE; then
- REAL_PREFIX=$ac_default_prefix
-else
- REAL_PREFIX=$prefix
-fi
+AS_AC_EXPAND(PREFIX, $prefix)
+AC_SUBST(PREFIX)
-## temporarily change prefix and exec_prefix
-old_prefix=$prefix
-prefix=$REAL_PREFIX
+AS_AC_EXPAND(BINDIR, $bindir)
+AC_SUBST(BINDIR)
-if test x$exec_prefix = xNONE ; then
- REAL_EXEC_PREFIX=$REAL_PREFIX
-else
- REAL_EXEC_PREFIX=$exec_prefix
-fi
-old_exec_prefix=$exec_prefix
-exec_prefix=$REAL_EXEC_PREFIX
+AS_AC_EXPAND(LIBDIR, $libdir)
+AC_SUBST(LIBDIR)
-BINDIR_TMP=$bindir
-EXPANDED_BINDIR=`eval echo $BINDIR_TMP`
-AC_SUBST(EXPANDED_BINDIR)
-AC_DEFINE_UNQUOTED(EXPANDED_BINDIR, $EXPANDED_BINDIR, [Where the executables are installed])
-
-## put prefix and exec_prefix back
-prefix=$old_prefix
-exec_prefix=$old_exec_prefix
+AS_AC_EXPAND(LIBEXECDIR, $libexecdir)
+AC_SUBST(LIBEXECDIR)
AC_ARG_ENABLE(more-warnings,
AC_HELP_STRING([--enable-more-warnings], [Maximum compiler warnings]),
Index: gnome/applet/Makefile.am
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/Makefile.am,v
retrieving revision 1.23.2.1
diff -u -r1.23.2.1 Makefile.am
--- gnome/applet/Makefile.am 19 Aug 2006 15:13:43 - 1.23.2.1
+++ gnome/applet/Makefile.am 10 Oct 2006 16:25:32 -
@@ -17,7 +17,7 @@
$(LIBGNOMEUI_CFLAGS)\
$(PANEL_APPLET_CFLAGS)\
$(GNOME_KEYRING_CFLAGS)\
- -DICONDIR=\$(datadir)/pixmaps\ \
+ -DICONDIR=\$(datadir)/icons\ \
-DGLADEDIR=\$(gladedir)\ \
-DBINDIR=\$(bindir)\\
-DSYSCONFDIR=\$(sysconfdir)\ \
Index: gnome/applet/applet.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet.c,v
retrieving revision 1.123.2.1
diff -u -r1.123.2.1 applet.c
--- gnome/applet/applet.c 19 Aug 2006 15:13:43 - 1.123.2.1
+++ gnome/applet/applet.c 10 Oct 2006 16:25:32 -
@@ -147,6 +147,9 @@
{
GObjectClass *gobject_class;
+ gtk_icon_theme_append_search_path (gtk_icon_theme_get_default (),
+ICONDIR);
+
gobject_class = G_OBJECT_CLASS (klass);
gobject_class-constructor = nma_constructor;
}
@@ -580,7 +583,7 @@
#else
msg = g_strdup_printf (span weight=\bold\ size=\larger\%s/span\n\n
%s\n\n%s, title, desc, error_msg);
- nma_show_vpn_failure_dialog (title, msg);
+ nma_show_failure_dialog (title, msg);
#endif
g_free (msg);
}
Index: gnome/dialup-properties/Makefile.am
===
RCS file: /cvs/gnome/NetworkManager/gnome/dialup-properties/Attic/Makefile.am,v
retrieving revision 1.1.2.2
diff -u -r1.1.2.2 Makefile.am
--- gnome/dialup-properties/Makefile.am 25 Aug 2006 10:56:14 - 1.1.2.2
+++ gnome/dialup-properties/Makefile.am 10 Oct 2006 16:25:32 -
@@ -26,7 +26,7 @@
$(LIBGNOMEUI_CFLAGS)\
$(DBUS_CFLAGS) \
-DSYSCONFDIR=\$(sysconfdir)\ \
-
[Patch] Don't activate networking on wake if it was disabled
Hey,
Here's a hack^W patch to keep the enabled/disabled state after waking up
from sleep. Currently, sleep is used for both sleep and disabling
networking so disable networking - suspend - resume results in enabled
networking. As Robert pointed out, it's especially bad when resuming on
an airplane since resume always enables networking.
To work around this problem without changing the public dbus api, I
added an optional boolean argument to sleep and wake methods to make
distinction between the two. For 0.7 branch we should probably do
something cleaner.
Tambet
Index: gnome/applet/applet-dbus-devices.c
===
RCS file: /cvs/gnome/NetworkManager/gnome/applet/applet-dbus-devices.c,v
retrieving revision 1.51.2.4
diff -u -r1.51.2.4 applet-dbus-devices.c
--- gnome/applet/applet-dbus-devices.c 17 May 2006 20:03:56 - 1.51.2.4
+++ gnome/applet/applet-dbus-devices.c 4 Oct 2006 12:21:39 -
@@ -1373,6 +1373,9 @@
if ((message = dbus_message_new_method_call (NM_DBUS_SERVICE, NM_DBUS_PATH, NM_DBUS_INTERFACE, method)))
{
+ gboolean true = TRUE; /* Eek... */
+
+ dbus_message_append_args (message, DBUS_TYPE_BOOLEAN, true, DBUS_TYPE_INVALID);
dbus_connection_send (applet-connection, message, NULL);
dbus_message_unref (message);
}
Index: src/NetworkManagerMain.h
===
RCS file: /cvs/gnome/NetworkManager/src/NetworkManagerMain.h,v
retrieving revision 1.25.2.1
diff -u -r1.25.2.1 NetworkManagerMain.h
--- src/NetworkManagerMain.h 6 Apr 2006 14:12:23 - 1.25.2.1
+++ src/NetworkManagerMain.h 4 Oct 2006 12:21:39 -
@@ -85,6 +85,7 @@
gbooleanwireless_enabled;
gbooleanmodem_active;
gbooleanasleep;
+ gbooleandisconnected;
GSList *dialup_list;
GMutex *dialup_list_mutex;
Index: src/nm-dbus-nm.c
===
RCS file: /cvs/gnome/NetworkManager/src/nm-dbus-nm.c,v
retrieving revision 1.39.2.2
diff -u -r1.39.2.2 nm-dbus-nm.c
--- src/nm-dbus-nm.c 21 May 2006 17:28:02 - 1.39.2.2
+++ src/nm-dbus-nm.c 4 Oct 2006 12:21:39 -
@@ -532,8 +532,28 @@
if (app_data-asleep == FALSE)
{
GSList *elt;
+ DBusMessageIter iter;
- nm_info (Going to sleep.);
+ dbus_message_iter_init (message, iter);
+
+ switch (dbus_message_iter_get_arg_type (iter)) {
+ case DBUS_TYPE_INVALID:
+ /* The boolean argument to differentiate between sleep and disabling networking
+ is optional and defaults to sleep */
+ app_data-disconnected = FALSE;
+ break;
+ case DBUS_TYPE_BOOLEAN:
+ dbus_message_iter_get_basic (iter, app_data-disconnected);
+ break;
+ default:
+ //bitch();
+ break;
+ }
+
+ if (app_data-disconnected)
+ nm_info (Disconnected.);
+ else
+ nm_info (Going to sleep.);
app_data-asleep = TRUE;
/* Not using nm_schedule_state_change_signal_broadcast() here
@@ -564,14 +584,36 @@
static DBusMessage *nm_dbus_nm_wake (DBusConnection *connection, DBusMessage *message, NMDbusCBData *data)
{
NMData *app_data;
+ DBusMessageIter iter;
+ gboolean enable_networking = FALSE;
g_return_val_if_fail (data data-data connection message, NULL);
+ dbus_message_iter_init (message, iter);
+
+ switch (dbus_message_iter_get_arg_type (iter)) {
+ case DBUS_TYPE_INVALID:
+ /* The boolean argument to differentiate between wake up from sleep and
+ enabling networking is optional and defaults to wake up. */
+ break;
+ case DBUS_TYPE_BOOLEAN:
+ dbus_message_iter_get_basic (iter, enable_networking);
+ break;
+ default:
+ //bitch();
+ break;
+ }
+
app_data = data-data;
- if (app_data-asleep == TRUE)
- {
- nm_info (Waking up from sleep.);
- app_data-asleep = FALSE;
+ /* Restore networking only if we're not disconnected or
+ enable_networking argument is passed. */
+ if (app_data-asleep (!app_data-disconnected || enable_networking)) {
+ if (enable_networking)
+ nm_info (Enabling networking.);
+ else
+ nm_info (Waking up from sleep.);
+
+ app_data-asleep = app_data-disconnected = FALSE;
/* Remove all devices from the device list */
nm_lock_mutex (app_data-dev_list_mutex, __FUNCTION__);
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[Patch] openvpn with TCP
Hey,
Here's a patch to make openvpn work with TCP port. NM uses --proto tcp
which, according to the manual page (and a bug #190940 in bnc), isn't
correct.
Tambet
Index: openvpn/properties/nm-openvpn.c
===
RCS file: /cvs/gnome/NetworkManager/vpn-daemons/openvpn/properties/nm-openvpn.c,v
retrieving revision 1.4.2.3
diff -u -r1.4.2.3 nm-openvpn.c
--- openvpn/properties/nm-openvpn.c 27 Sep 2006 15:10:23 - 1.4.2.3
+++ openvpn/properties/nm-openvpn.c 2 Oct 2006 12:10:59 -
@@ -225,7 +225,7 @@
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (impl-w_use_tap), TRUE);
should_expand = TRUE;
} else if ( (strcmp (key, proto) == 0)
- (strcmp (value, tcp) == 0) ) {
+ (strcmp (value, tcp-client) == 0) ) {
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (impl-w_use_tcp), TRUE);
should_expand = TRUE;
} else if (strcmp (key, cipher) == 0) {
@@ -328,7 +328,7 @@
data = g_slist_append (data, g_strdup (remote));
data = g_slist_append (data, g_strdup (remote));
data = g_slist_append (data, g_strdup (proto));
- data = g_slist_append (data, use_tcp ? g_strdup (tcp) : g_strdup(udp));
+ data = g_slist_append (data, use_tcp ? g_strdup (tcp-client) : g_strdup(udp));
data = g_slist_append (data, g_strdup (ca));
data = g_slist_append (data, g_strdup (ca));
data = g_slist_append (data, g_strdup (cert));
@@ -980,7 +980,7 @@
should_expand = TRUE;
}
- if ( strcmp (proto, tcp) == 0 ) {
+ if ( strcmp (proto, tcp-client) == 0 ) {
gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (impl-w_use_tcp), TRUE);
should_expand = TRUE;
}
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [Patch] openvpn with TCP
On Mon, 2006-10-02 at 10:06 -0400, Dan Williams wrote: Patch looks fine; but did OpenVPN previously use 'tcp'? Or has it always used 'tcp-client'? It seems odd that there is a 'udp' option, but the TCP option is called 'tcp-client'. I'd expect it to be either 'tcp' 'udp', or 'tcp-client' 'udp-client'. I don't want to break stuff on an upgrade unless we know exactly what we're breaking. From the information I could gather (mostly from openvpn ChangeLog), it looks like 'tcp' is provided as a shortcut, but only works if the '-server' or '-client' part can be guessed (from --mode I think). The first time '--proto tcp-client' is mentioned in the ChangeLog is from 2004.01.14 -- Version 1.6-beta1. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
