Agreement to relicense NetworkManager under LGPL-2.1+
I, Tambet Ingo, agree to relicense my contributions to NetworkManager as LGPL-2.1+ as proposed by Thomas Haller. Some of my work may be held under copyright by Novell, Inc. I do not speak for that entity. Tambet ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Are there any command-line front-ends for network-manager?
On Wed, Jan 20, 2010 at 02:53, Dan Williams d...@redhat.com wrote: In general uou'll want to *configure* connections using your distro's normal network configuration system (which NetworkManager should pick up automatically) In general, I think it's a bad suggestion. The distro networking tools are (usually?) for configuring one static configuration per device which does not really match well with NetworkManager. For example, using distro tools, I create a connection for SSID mywlan. It becomes one of many connection profiles in NetworkManager and you'd be very surprised to see NM connected to another network instead. Another example, you configure a device and use don't connect automatically, let user activate it manually. Again, it becomes one of available configurations for the device, and NM will happily activate the device automatically with another connection data, seemingly ignoring that it was told to not connect automatically. In short, as long as there's more than one connection profile available, it's not guaranteed that the distro configuration is used. Because of that, (and countless bugs from confused users) I've disabled support of using distro network configuration for NetworkManager for openSUSE packages (and received only a few complaints, so people seem to be happier now). If we really care about CLI only NetworkManager, we'll need to write a nm-connection-editor type of CLI thing too. Or if we want to support distro tools, make it harder (impossible?) to use more than one connection profile per device. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Lockdown nm-applet once again
On Wed, Jan 20, 2010 at 02:07, Dan Williams d...@redhat.com wrote: On Tue, 2010-01-12 at 10:30 +0100, van Schelve wrote: Hi. In the archives I have found this entry: http://www.mail-archive.com/networkmanager-list@gnome.org/msg13808.html The question that was talked about there was how to lockdown the nm-applet. I have successfully tried to lockdown the nm-applet by changing the dbus config as descripted by Dan. It looks like this would be a valid workaround. But I don't know if it is possible to have this config part in a seperate file? I didn't found anything useful in the freedesktop dbus documentation for this question. For enable networking and enable wifi/wwan, the best way would be with PolicyKit. Unfortunately that's not quite implemented yet and we'll need to do a bit of work to PK-enable these properties since dbus-glib doesn't have an easy way of intercepting property get/set calls. But that's the perfect future :) We (Novell) wrote full PK support to lockdown pretty much everything in NM. I believe Lance Wang worked on that, Lance, can you share the patch so it can be included in upstream? Tambet In general it would be very fine to configure the whole nm-applet in a single config file (f.e. /etc/NetworkManager/nm-applet.conf). Currently there are three steps to lockdown nm-applet: 1. dbus config to disalbe the enable/disable Network option 2. gconf for notification behaviour 3. chmod, selinux, apparmor or whatever for nm-connection-editor I believe that in general the two places for lockdown should be PolicyKit (for NM in general) and GConf (for nm-applet specifically). PolicyKit lets administrators lock down the behavior for *all* clients generically (command-line, Gnome, KDE) while applet-specific behavior gets locked down by that desktop environment's normal methods. I'd hope that in this bright shiny future you'd never have to deal with either (1) or (3) from your list above since it would already be handled by PK and GConf/K-whatever. Dan ___ 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: Questions about ModemManager
On Fri, Sep 25, 2009 at 12:50, Ozan Çağlayan o...@pardus.org.tr wrote: 1. After calling Connect() and using PPPD to create a PPP connection through a modem, how should I cleanly disconnect from device? I first terminate PPPD and then call Disconnect() over D-Bus but after that I'm having serial connection timeouts over MM if I recall Connect() a second time. What's the purpose of Disconnect()? Should it be used? It doesn't seem to send some AT commands at all as the --debug output of MM stays intact after Disconnect() calls. Disconnect() can't send any AT commands, the device is in use and doesn't accept any commands. MM instead sets the sport speed to 0 bps, just like other terminal handling programs do. I suspect pppd does the same thing, so it doesn't really matter whether you terminate pppd or call Disconnect(), the result should be exactly the same. It might be a good idea to call Disconnect() too, in case pppd segfaults on shutdown or something. 2. What does 'No cause information available' means? ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'CRLF+CME ERROR: 11CRLF' ** (modem-manager:7311): DEBUG: Got failure code 11: SIM PIN required ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'AT+CFUN=1CR' ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'CRLFOKCRLF' ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'AT+CSQCR' ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'CRLF+CME ERROR: 11CRLF' ** (modem-manager:7311): DEBUG: Got failure code 11: SIM PIN required ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'AT+CPIN=CR' ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'CRLFOKCRLF' ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'AT+CSQCR' ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'CRLF+CSQ: 13,99CRLFCRLFOKCRLF' ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'ATDT*99#CR' ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'CRLFNO CARRIERCRLF' ** (modem-manager:7311): DEBUG: Got failure code 3: No carrier ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'AT+CEERCR' ** (modem-manager:7311): DEBUG: (ttyUSB0): -- 'CRLF+CEER: No cause information availableCRLFCRLFOKCRLF' +CEER command is supposed to return the reason why dial command failed. Your modem has no idea why it failed. 3. What does Enable() exactly do on the device? It does whatever is necessary to turn your modem on so that it is ready for use (registration). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Do we have plan to do finer grained PolicyKit support for Networkmanager?
On Fri, Sep 18, 2009 at 16:10, Lance Wang lance@gmail.com wrote: On Thu, Sep 17, 2009 at 2:11 PM, Tambet Ingo tam...@gmail.com wrote: On Thu, Sep 17, 2009 at 06:16, Bin Li libin.char...@gmail.com wrote: To disallow users to define their own network configuration, I add a new permission, org.freedesktop.network-manager-settings.user.modify, then link to the add button, when the user have permission, he can add it, vice versa. I've met a problem, the user's connection save in the gconf, and the user can change the gconf with gconftool-2 without permission checking. So are there any method to resolve this problem? And is it okay to do like this? Any idea? This makes no sense. You can already lock GConf so there's no need to do anything for user settings. Just lock the /system/networking path in gconf and the settings can't be changed. The only thing you could improve, is to make sure nm-applet and nm-connection-editor handle it more gracefully, ie gray out the apply button etc... It make no sense that gray out the apply button etc, I think, I'm sorry if I offended you, I didn't mean to. when the /system/networking path is locked. Because if it is locked all buttons should be gray out. Maybe we should not show the nm-connection-editor, as on average if someone was not permitted to modify user settings, he or she would be denied to modify the system settings. And another aspect. I think we should leave the control in the NetworkManager side. As far as I know, all settings should be apply through NetworkManager. If we just lock gconf, people with malicious intent can still use modified nm-applet to apply the user settings they want. So I think there may be a policy action such as org.freedesktop.network-manager-settings.user.apply. Every time NetworkManager receive the request to apply the user settings, it should check the action. And nm-connection-editor also check the action to set the button status. Further more maybe we split the policy to org.freedesktop.network-manager-settings.user.wired.apply org.freedesktop.network-manager-settings.user.wireless.apply org.freedesktop.network-manager-settings.user.vpn.apply etc... What do you think? I think in situations you describe NM should not accept user connections at all and rely only on system settings that already need root privileges to change. I don't see why we need two duplicate systems for controlling one thing. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Do we have plan to do finer grained PolicyKit support for Networkmanager?
On Thu, Sep 17, 2009 at 06:16, Bin Li libin.char...@gmail.com wrote: To disallow users to define their own network configuration, I add a new permission, org.freedesktop.network-manager-settings.user.modify, then link to the add button, when the user have permission, he can add it, vice versa. I've met a problem, the user's connection save in the gconf, and the user can change the gconf with gconftool-2 without permission checking. So are there any method to resolve this problem? And is it okay to do like this? Any idea? This makes no sense. You can already lock GConf so there's no need to do anything for user settings. Just lock the /system/networking path in gconf and the settings can't be changed. The only thing you could improve, is to make sure nm-applet and nm-connection-editor handle it more gracefully, ie gray out the apply button etc... Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Question about function applet_get_best_activating_connection()
On Wed, Sep 16, 2009 at 05:54, 代尔欣 daier...@gmail.com wrote:
Hi all,
In applet.c function applet_get_best_activating_connection() have codes:
...
if (NM_IS_DEVICE_WIFI (best_dev)) {
if (NM_IS_DEVICE_ETHERNET (candidate)) {
best_dev = candidate_dev;
best = candidate;
}
}
...
Is NM_IS_DEVICE_ETHERNET (candidate) correct? The 'candidate' type is
NMActiveConnection. It should use candidate_dev instead?
Fixed, thanks!
Tambet
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Do we have plan to do finer grained PolicyKit support for Networkmanager?
On Thu, Sep 17, 2009 at 12:14, Bin Li libin.char...@gmail.com wrote: On Thu, Sep 17, 2009 at 2:11 PM, Tambet Ingo tam...@gmail.com wrote: On Thu, Sep 17, 2009 at 06:16, Bin Li libin.char...@gmail.com wrote: To disallow users to define their own network configuration, I add a new permission, org.freedesktop.network-manager-settings.user.modify, then link to the add button, when the user have permission, he can add it, vice versa. I've met a problem, the user's connection save in the gconf, and the user can change the gconf with gconftool-2 without permission checking. So are there any method to resolve this problem? And is it okay to do like this? Any idea? This makes no sense. You can already lock GConf so there's no need to do anything for user settings. Just lock the /system/networking path in gconf and the settings can't be changed. The only thing you could improve, is to make sure nm-applet and nm-connection-editor handle it more gracefully, ie gray out the apply button etc... Tambet, Thanks! And the lock means let the /system/networking store in mandatory directory? Yes, and there are tools that help you achieve that, sabayon (http://projects.gnome.org/sabayon/) for example. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[Patch] Export NM version over dbus
Hey,
Attached patch exports the NetworkManager version over DBus.
Currently, it's probably mostly needed to determine whether the NM
daemon is 0.7 or 0.8, so if this new property isn't implemented, it's
0.8.
Tambet
From 7234456990bba45f6c9cbe69df01cd94ee160759 Mon Sep 17 00:00:00 2001
From: Tambet Ingo tam...@gmail.com
Date: Mon, 14 Sep 2009 13:17:42 +0300
Subject: [PATCH] Export NetworkManager version over DBus.
diff --git a/introspection/nm-manager-client.xml b/introspection/nm-manager-client.xml
index cf89611..2714c64 100644
--- a/introspection/nm-manager-client.xml
+++ b/introspection/nm-manager-client.xml
@@ -43,6 +43,7 @@ object. dbus-glib generates the same bound function names for D-Bus the methods
property name=WirelessHardwareEnabled type=b access=read/
property name=ActiveConnections type=ao access=read/
property name=State type=u access=read/
+property name=Version type=s access=read/
signal name=StateChanged
arg name=state type=u/
diff --git a/introspection/nm-manager.xml b/introspection/nm-manager.xml
index a93ee58..80ecbb9 100644
--- a/introspection/nm-manager.xml
+++ b/introspection/nm-manager.xml
@@ -113,6 +113,12 @@
/tp:docstring
/property
+property name=Version type=s access=read
+ tp:docstring
+ The NetworkManager version.
+ /tp:docstring
+/property
+
signal name=StateChanged
tp:docstring
NetworkManager's state changed.
diff --git a/libnm-glib/nm-client.c b/libnm-glib/nm-client.c
index 07f77ce..80a002c 100644
--- a/libnm-glib/nm-client.c
+++ b/libnm-glib/nm-client.c
@@ -55,6 +55,7 @@ typedef struct {
DBusGProxy *bus_proxy;
gboolean manager_running;
NMState state;
+ char *version;
GPtrArray *devices;
GPtrArray *active_connections;
@@ -328,6 +329,8 @@ dispose (GObject *object)
free_object_array (priv-devices);
free_object_array (priv-active_connections);
+ g_free (priv-version);
+
G_OBJECT_CLASS (nm_client_parent_class)-dispose (object);
}
@@ -569,6 +572,8 @@ proxy_name_owner_changed (DBusGProxy *proxy,
} else {
_nm_object_queue_notify (NM_OBJECT (client), NM_CLIENT_MANAGER_RUNNING);
update_wireless_status (client, TRUE);
+ g_free (priv-version);
+ priv-version = NULL;
}
}
@@ -900,6 +905,29 @@ nm_client_get_state (NMClient *client)
}
/**
+ * nm_client_get_version:
+ * @client: a #NMClient
+ *
+ * Gets the current daemon version.
+ *
+ * Returns: the current NetworkManager version
+ **/
+const char *
+nm_client_get_version (NMClient *client)
+{
+ NMClientPrivate *priv;
+
+ g_return_val_if_fail (NM_IS_CLIENT (client), NULL);
+
+ priv = NM_CLIENT_GET_PRIVATE (client);
+
+ if (!priv-version)
+ priv-version = _nm_object_get_string_property (NM_OBJECT (client), NM_DBUS_INTERFACE, Version);
+
+ return priv-version;
+}
+
+/**
* nm_client_sleep:
* @client: a #NMClient
* @sleep: %TRUE to put the daemon to sleep
diff --git a/libnm-glib/nm-client.h b/libnm-glib/nm-client.h
index 5af95d4..c9b1b04 100644
--- a/libnm-glib/nm-client.h
+++ b/libnm-glib/nm-client.h
@@ -82,6 +82,7 @@ gboolean nm_client_wireless_get_enabled (NMClient *client);
void nm_client_wireless_set_enabled (NMClient *client, gboolean enabled);
gboolean nm_client_wireless_hardware_get_enabled (NMClient *client);
NMState nm_client_get_state(NMClient *client);
+const char *nm_client_get_version(NMClient *client);
gboolean nm_client_get_manager_running (NMClient *client);
const GPtrArray *nm_client_get_active_connections (NMClient *client);
void nm_client_sleep(NMClient *client, gboolean sleep);
diff --git a/src/nm-manager.c b/src/nm-manager.c
index 8c82f87..c94fe6b 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -19,6 +19,8 @@
* Copyright (C) 2007 - 2009 Red Hat, Inc.
*/
+#include config.h
+
#include netinet/ether.h
#include string.h
#include dbus/dbus-glib-lowlevel.h
@@ -210,6 +212,7 @@ enum {
PROP_WIRELESS_ENABLED,
PROP_WIRELESS_HARDWARE_ENABLED,
PROP_ACTIVE_CONNECTIONS,
+ PROP_VERSION,
/* Not exported */
PROP_HOSTNAME,
@@ -2725,6 +2728,9 @@ get_property (GObject *object, guint prop_id,
case PROP_ACTIVE_CONNECTIONS:
g_value_take_boxed (value, get_active_connections (self, NULL));
break;
+ case PROP_VERSION:
+ g_value_set_string (value, VERSION);
+ break;
case PROP_HOSTNAME:
g_value_set_string (value, priv-hostname);
break;
@@ -2842,6 +2848,14 @@ nm_manager_class_init (NMManagerClass *manager_class)
DBUS_TYPE_G_ARRAY_OF_OBJECT_PATH,
G_PARAM_READABLE));
+ g_object_class_install_property
+ (object_class, PROP_VERSION,
+ g_param_spec_string (NM_MANAGER_VERSION,
+ Version,
+ NetworkManager version,
+ NULL,
+ G_PARAM_READABLE));
+
/* Hostname is not exported over D-Bus */
g_object_class_install_property
(object_class, PROP_HOSTNAME,
diff --git a/src
Re: Bug report for connecting to eap-tls wireless network with a CA chain
On Wed, Sep 9, 2009 at 05:05, zignz...@zign.cn wrote: Hi, I think I got a bug in network-manager 7.0.100 and 7.1 when connecting to eap-tls wireless network with a CA chain. I found that the Network-manager only pass the the first CA cert to the wpa_supplicant if you have more than one CA cert in the file, which may result in the connection failure. https://bugzilla.gnome.org/show_bug.cgi?id=594466 The description there is probably not very clear, but it's the same thing. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-netbook with NetworkManager 0.8
On Tue, Sep 1, 2009 at 02:47, Peter Robinsonpbrobin...@gmail.com wrote: I've been looking at the recent break of network-manager-netbook in rawhide. I was hoping it was going to be the simple fix that I needed to apply to mojito I was wrong :( . Digging deeper it looks like a lot of the patch that was applied to network-manager-applet [1] also applies to network-manager-netbook. I'm not sure I have the NetworkManager prowess to migrate the patch across so any helpers, pointers and assistance would be greatly appreciated :) Someone simply needs to port network-manager-netbook to libnm_glib-0.8. Since we (Novell) can't use 0.8 in our next release (11.2) because NM releases tend to be synced with Fedora releases (which happens after our release), it hasn't been in my TODO list. The patch you reference does a lot more and the actual needed patch would be much smaller. I'm not sure how the support for 0.8 would be implemented while keeping it compatible with 0.7, I'm not a fan of #ifdefs. Nor am I a fan of keeping two branches in sync... For anyone else interested in packaging network-manager-netbook, I have a couple of patches for NetworkManager as well to make it integrate better in moblin environment. One patch renames automatic connections Auto ethX to Wired since netbooks usually don't have multiple ethernet devices. One patch modifies the PolicyKit permissions to allow all users modify system connections - netbooks aren't usually multi-user machines and we need to change the connect automatically property of the system ethernet connection when the user clicks on Disconnect. The last patch downs all modems in addition to wifi devices when WirelessEnabled is disabled. Let me know if you're interested in any of these patches and can't find them from build.opensuse.org. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network-manager-netbook with NetworkManager 0.8
On Wed, Sep 2, 2009 at 15:39, Alexander Sacka...@ubuntu.com wrote: On Wed, Sep 02, 2009 at 02:31:31PM +0300, Tambet Ingo wrote: connections Auto ethX to Wired since netbooks usually don't have I was asked by our user experience team to do something about reducint the technical terms used for the auto connections. So I think it would be worthwhile to think about improving this in NM everywhere. Maybe we can use Wired and in case there are more than one devices use Wired 2 etc. ? I wouldn't have a problem with that. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: APN list: adding mcc mnc
On Wed, Apr 22, 2009 at 11:17, Martijn Cox (LiveContacts) m@livecontacts.com wrote: Sorry for the delayed response, I have been busy otherwise. Attached, you'll find our complete list of mncmcc tagged APN's. As stated before, not all apns are tagged with the correct mcc's and mnc's; some apns have the '123456789' marker for either country, network code or both, which means we don't know how to link the apn to a particular mcc mnc (simply because we couldn't find that information or didn't have the time to search longer). Does the format in which we supplied mcc and mnc information to the list suit everybody's needs? It works well for us. It doesn't work well for NetworkManager. There's no way to construct the network id (which NM requires) based on provider when the country has more than one MCC. Here's my proposal: Add mcc and mnc attributes to each 'provider' tag, so it would look something like: provider mcc=248 mnc=02 nameElisa/name ... /provider or, if people hate attributes (as it appears from the current schema :), just tags inside provider: provider mcc248/mcc mnc02M/mnc nameElisa/name ... /provider or, just one attribute/tag for mcc/mnc code, it's not rocket science to split it in code (if needed): provider code=24802 ... /provider Tambet Regards, Martijn -Original Message- From: stuart.ward...@googlemail.com [mailto:stuart.ward...@googlemail.com] On Behalf Of Stuart Ward Sent: donderdag 16 april 2009 19:21 To: Dan Williams Cc: Martijn Cox (LiveContacts); networkmanager-list@gnome.org; wader-de...@lists.warp.es Subject: Re: APN list: adding mcc mnc The only to do this sensibility is to allocate a mcc / mnc pair for each network entry. Yeah, that's probably the best solution. Dan I have a speadsheet with all the codes on it though I was looking through and it has quite a few inconsistancies and issues in it. It com from the GSMA but each network filles in their own data and some of them do thin=s in diffrent ways. As well some of the data is somewhat out of date. Been trying for some time to find the time to tidy this up but I am not sure how to merge all this into the existing xml ___ 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: Issue with Auto eth0
On Fri, Apr 3, 2009 at 10:51, Hooker, Jonathan jonathan.hoo...@garmin.com wrote: Ok, thanks! One more question... My developers use a usb ethernet connection to connect to their development devices. Is there any way to tell NM to default to eth0 always and when the usb0 gets plugged in to automatically connect to it as a second ethernet connection? Yes, that is also the default behavior. If both devices just need to use DHCP, then one connection data is enough and both devices can use it. There's a MAC address field in the connection editor to tie the configuration with specific device. If you require different connection settings, create two connections and specify the MAC address on both to lock the connection data to specific device. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Issue with Auto eth0
On Fri, Apr 3, 2009 at 12:59, Hooker, Jonathan jonathan.hoo...@garmin.com wrote: Ok. One more question... Is there a reason why I can not just create a file in /etc/NetworkManager/system-connections that has all of the right settings and NM just pick it up? I am having to change certain fields in the config and I just figured I could just use a perl script to replace the whole file... Sure you can, it's a .ini-like file. I didn't suggest it in the first place because it's not documented anywhere what the known keys and value formats are. But if you've already created it once, you see the keys and value formats and you can change it using any text editor or script. nm-system-settings daemon monitors the /etc/NetworkManager/system-connections directory and automatically adds new connections. It also monitors the file changes there to automatically update the connection data in NetworkManager as soon the files change. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: network manager::memory and resource leaks
On Wed, Mar 25, 2009 at 01:14, Martin Ettl ettl.mar...@gmx.de wrote: Hi friends, i examined the source code of the network manager with a static code anaylsis tool (cppcheck). It brought up a few little issues. But see yourself: cppcheck -a -q -j2 -f NetworkManager-0.7.0.99 [NetworkManager-0.7.0.99/callouts/nm-dispatcher-action.c:754]: (error) Memory leak: d This is bogus, the next line is the end of program. [NetworkManager-0.7.0.99/src/named-manager/nm-named-manager.c:321]: (error) Resource leak: f The tool must not understand pclose(), this is not a leak. [NetworkManager-0.7.0.99/system-settings/src/main.c:852]: (error) Memory leak: app Again bogus, the next line is the end of program. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM 0.7.1 rc3 oddness with 3G USB device
On Mon, Mar 9, 2009 at 21:05, Dan Williams d...@redhat.com wrote: Mobile broadband capabilities are detected with udev capabilities now too, but the problem here is that nothing reports which channel is the control channel and which isn't. That information need to go into the driver somewhere like it does for 'hso' type devices. I don't know; maybe asac is right and we do need to prefer HAL over udev at least for 0.7.1. I agree with asac then. With any modem other than HSO, you have no idea from probing which port is the control port and which just accepts AT commands. With HAL, while things are fragile and require manual updates, there's at least a chance it works. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: dbus and OpenVPN Autostart
On Mon, Feb 9, 2009 at 18:47, Dan Williams d...@redhat.com wrote:
On Mon, 2009-02-09 at 11:37 +1100, David Guest wrote:
I am attempting to create a dispatcher script to autostart an OpenVPN
connection, I am stuck on how to get the vpn to connect through dbus.
Would anyone have a working example, preferably in python but any
language will do?
I am running Ubuntu 8.10 (NetworkManager 0.7), I have found at least one
example on the web but it appears to be for an earlier dbus Network
Manager API version as I get errors when running them.
I have looked at the 0.7 dbus API but can't figure out what to send to
the org.freedesktop.NetworkManager.VPN.Plugin.Connect method or even if
this is the right approach?
That's actually the wrong approach here; what you want to do is tell
_NetworkManager_ to connect the VPN connection. So you'll be using the
org.freedesktop.NetworkManager.ActivateConnection method, and pass it
the service name of the settings service (either user or system) that
provides the connection, the object path of the connection as exported
by that settings service, and the device you'd like to activate the VPN
on (which would be the object path of the interface your script got
called with, probably).
This functionality is very often requested and a dispatcher script to
do that is quite hard to implement. I wrote a script to do that, see
the attachment. It needs some configuration first: The UUID of the VPN
connection you'd like to get automatically activated, the UUID of the
connection with which you want your VPN automatically activated, and
the UID of the user who has the VPN connection defined. For the first
two, just run the script without any arguments and it'll print out all
known connections and their UUIDS. Find your UID with `id -u`. After
changing these variables in the beginning of the script with your
data, copy it to /etc/NetworkManager/dispatcher.d/ and make sure it's
executable.
Dan, maybe it makes sense to add some example dispatcher scripts to
the tree, starting with this one? There's a lot you can do with these,
change active printers, proxies, mounts, ..., and many people have no
idea how useful they can be.
Tambet
#!/usr/bin/python
# Run this script without any arguments to list the available connection uuids.
# The uuid of the VPN connection to activate
#VPN_CONNECTION_UUID=ddf87e7a-15f4-4db0-a41d-f79edf12b44d
VPN_CONNECTION_UUID=
# The uuid of the connection that needs to be active to start the VPN connection
#ACTIVE_CONNECTION_UUID=b5c1c880-2060-421c-9c96-535bf8910313
ACTIVE_CONNECTION_UUID=
# UID to use. Note that NM only allows the owner of the connection to activate it.
#UID=1000
UID=0
import sys
import os
import dbus
from dbus.mainloop.glib import DBusGMainLoop
import gobject
DBusGMainLoop(set_as_default=True)
def get_connections():
bus = dbus.SystemBus()
proxy = bus.get_object('org.freedesktop.NetworkManagerUserSettings', '/org/freedesktop/NetworkManagerSettings')
iface = dbus.Interface(proxy, dbus_interface='org.freedesktop.NetworkManagerSettings')
return iface.ListConnections()
def get_connection_by_uuid(uuid):
bus = dbus.SystemBus()
for c in get_connections():
proxy = bus.get_object('org.freedesktop.NetworkManagerUserSettings', c)
iface = dbus.Interface(proxy, dbus_interface='org.freedesktop.NetworkManagerSettings.Connection')
settings = iface.GetSettings()
if settings['connection']['uuid'] == uuid:
return c
return None
def list_uuids():
bus = dbus.SystemBus()
for c in get_connections():
proxy = bus.get_object('org.freedesktop.NetworkManagerUserSettings', c)
iface = dbus.Interface(proxy, dbus_interface='org.freedesktop.NetworkManagerSettings.Connection')
settings = iface.GetSettings()
conn = settings['connection']
print %s - %s (%s) % (conn['uuid'], conn['id'], conn['type'])
def get_active_connection_path(uuid):
bus = dbus.SystemBus()
proxy = bus.get_object('org.freedesktop.NetworkManager', '/org/freedesktop/NetworkManager')
iface = dbus.Interface(proxy, dbus_interface='org.freedesktop.DBus.Properties')
active_connections = iface.Get('org.freedesktop.NetworkManager', 'ActiveConnections')
all_connections = get_connections()
for a in active_connections:
proxy = bus.get_object('org.freedesktop.NetworkManager', a)
iface = dbus.Interface(proxy, dbus_interface='org.freedesktop.DBus.Properties')
path = iface.Get('org.freedesktop.NetworkManager.Connection.Active', 'Connection')
proxy = bus.get_object('org.freedesktop.NetworkManagerUserSettings', path)
iface = dbus.Interface(proxy, dbus_interface='org.freedesktop.NetworkManagerSettings.Connection')
settings = iface.GetSettings()
if settings['connection']['uuid'] == uuid:
return a
return None
def activate_connection(vpn_connection, active_connection):
def
Re: [RFC] Make scan mode configurable
On Tue, Feb 10, 2009 at 12:45, Daniel Wagner w...@monom.org wrote: BTW, I have small python/qt application here[1] which allows you to play around with it. What would call the API you added (other than your test program)? Who would want/need to use that UI? Is it wireless device specific? If it's card specific, then we can do the right thing in the NM without asking users to try random options if something doesn't feel right. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [RFC] Make scan mode configurable
On Tue, Feb 10, 2009 at 14:20, Daniel Wagner w...@monom.org wrote: On Tue, Feb 10, 2009 at 01:12:02PM +0200, Tambet Ingo wrote: What would call the API you added (other than your test program)? Good question. I assumed this could be an option in the nm-applet. The problem is there's no place to put it there. There's no per-device configuration location anywhere, all the configuration is NMConnection specific. Who would want/need to use that UI? I can just write about the problem I wanted to fix. The time needed to recognize there is a new AP or an AP disappeared was just too long. Of course if you don't have a fast changing network setup this is not really problem. This is all about moving around with your laptop/device and if it takes 120 seconds to see there is a new AP and 360 seconds to remove the AP from the list is just a bit too long IHMO. Can you use wireless when you move that fast? :) Surely you can't stay connected to any of the APs? If I didn't get it completely wrong, connman uses continuously scanning to overcome this problem. That's exactly what I meant by being device specific. Connman only cares about a few selected wireless cards that support passive scanning, NM needs to also work on cards where a scan request takes noticeable amount of time (when no other IP traffic could be sent). Is it wireless device specific? The patch allows to set the scan interval for each device separately. Basically the patch just changes default behavior in NM. The scan is still triggered through the wpa_supplicant interface. If it's card specific, then we can do the right thing in the NM without asking users to try random options if something doesn't feel right. No, it is not card specific. Okay I think you are right about Sounds like it still is. offering users too many knobs to play with. How do you propose to fix my use case? I don't know much about wireless drivers, but maybe a new capability for drivers, IW_SCAN_CAPA_SOMETHING? Dan or Helmut will have a better answer. But having UI for something like I want my wireless APs appear/disappear faster is certainly not a solution, everybody wants that. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
NetworkManager integrated with ModemManager
Hi, I'm pleased to announce the git master branch of NetworkManager now uses ModemManager for all operations with modems (discovery, connecting, disconnecting, ...). Get the latest ModemManager from http://people.freedesktop.org/~tambet/ModemManager-0.2.tar.gz or clone it from git://anongit.freedesktop.org/ModemManager/ModemManager ModemManager is used only if available using DBus, so it's not a build time dependency (reduces ~1000 lines of 'bloat' when you don't need modems). If this change broke modem connections for you, please enable ModemManager debugging (either by sending SIGUSR1 to 'modem-manger' process or by running it with --debug), try to activate the modem and when it fails, send the ModemManager debug output to the list. One of the main reasons for ModemManager is to make it easy to add modem specific workarounds for specific modems but if you don't share your failures, they never make it to the releases. It also means you can write your own ModemManager implementation by having just two DBus methods (see 'org.freedesktop.ModemManager.Modem.Simple' from ModemManager for more information). An interface to 'umtsmon' anyone? wvdial? comgt? Your favorite tool can now be integrated with stock NetworkManager! Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager integrated with ModemManager
On Mon, Feb 9, 2009 at 15:14, Darren Albers dalb...@gmail.com wrote: With ModemManager will the workarounds have to be done in the code or is there some method that an end-user can drop chat script in to ModemManager? For example I have a Blackberry that I tether using Barry and it has a non-standard method of creating a serial port. I would like to help get this working but I am not much of a developer. The workarounds are implemented in ModemManager as plugins in C. I find it hilarious how people miss having to know AT commands by heart and to be required to enter them to get their modem connected. I understand it could be the only way to get your modem connected, but that problem should be fixed by developers, not by users. Sort of the point of whole NM, to make things just work. All that said... I've been planning to write a ModemManager plugin that does exactly that, but not to torture people, but to make it easier for them to contribute back - if we can see which commands are required for certain modem, we can do that in ModemManager. Ahh I think I see now, so we would need to write an interface to something like wvdial or even direct to Barry for this to work? While it's possible to use anything (like wvdial, barry), it usually doesn't make much sense (other than for testing). There can be exactly one DBus service that provides ModemManager API so the distro can not ship the hack which only works with your modem (so you'll never have an works-out-of-box solution). I guess what you're really asking for, is Bluetooth support and that's still missing. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DBus permissions
On Tue, Jan 27, 2009 at 14:40, Michael Biebl bi...@debian.org wrote: Tambet Ingo wrote: Attached patches fix DBus permissions for all NetworkManager pieces (NM, nm-applet, vpn plugins). For more information, see http://lists.freedesktop.org/archives/dbus/2009-January/010807.html wouldn't it make sense though, to keep the default deny rules in case you are still using an older dbus version? They don't hurt and would make it easier to provide backports for already released distros. The security issue has always been there, so if your distro intends to update NM, surely it would want to fix DBus security issues as well? Also, from distro's perspective, wouldn't it be easier to just change the default rule than add deny policies to each and every policy file? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DBus permissions
On Tue, Jan 27, 2009 at 15:32, Michael Biebl bi...@debian.org wrote: I think it is not so much about adding those application specific deny rules, but more about keeping them. If I look through the policy files currently installed on my system, basically all of them have a policy context=default deny .../ deny .../ /policy Yes, they do have broken deny send_interface=foo/ items, that's the point of the patches. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [Fwd: Aircard USB Modem doesn't work on SUSE 11.1,]
On Thu, Jan 15, 2009 at 07:20, Guillermo Lloreda Diaz gllor...@gmail.com wrote: I have installed Suse 11.1 and at the end the installation showed an error saying: 'No Network running' I hit OK and the installation continued until the end without any problem. On booting I notice that that the USB Aircard was detected correctly and was setup axactly as it did on Suse 11.0 but when I tried to connect to the Internet Netmanager stalled, no connection at all. It does not do anything.' I ran '/usr/bin/lsusb' and here is the result: bus 002 Device 003: ID 1199:0120 Sierra Wireless, Inc AC595U. I don't know what to do ,please help Please open a bug on http://bugzilla.novell.com and attach your /var/log/NetworkManager file there. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: GNOME-NetworkManager fails to recognise WLAN Interface
On Thu, Jan 8, 2009 at 11:46, Pradeep Gurumath pradeepgurum...@gmail.com wrote: We are integrating Wireless LAN driver with GNOME on a customer proprietary board. The issue we are facing is that our network interface (WLAN) does not appear in the GNOME-NetworkManager Applet. We need to identify, configure and connect to various network interfaces available in the system - in particular, the WLAN interface. However the GNOME-NetworkManager (version 0.7) fails to recognise the available network interfaces. As a result, when we click on the nw interfaces icon on the top right corner of the screen, the nw Interfaces are not being shown. As soon as the NetworkManager applet comes up during the boot, we get the following warning, ** (nm-applet:2760): WARNING **: No connections defined ** (nm-applet:2760): WARNING **: No networks found in the configuration database Meanwhile, when we try running the command 'ifconfig', it shows all the available NW Interfaces including the WLAN interface. We are even able to configure, connect and browse the web (using both wget and web2) using the Command Line Interface. So we are sure that the available wireless NW Interface is working properly. With this, we even rule out the possibility of wpa_supplicant being the source of the problem. Few of the things we have tried so far 1) Changed the /etc/network/interface to include our WLAN interface. 2) Made the WLAN interface up before even the NetworkManager applet is started. 3) Restarted the NetworkManager applet to force it to refresh the nw interface list. 4) Restarted the default wpa_supplicant to see if it helps the matter. We want to know if we are missing some sort of configuration in any init scripts which feeds the NetworkManager as to where to pick up the NW interfaces from. If anybody has worked on the GNOME-Network Manager earlier or has a clue about this, kindly share with us. nm-applet is a frontend for NetworkManager daemon and presents the information from NM. NetworkManager uses HAL to get it's devices. It looks for HAL UDIs which' info.capability property has string net.80211 (wifi) or net.80203 (ethernet). So if a device is missing from NM, first make sure HAL recognizes the device as a network device. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: specifications
On Sun, Jan 4, 2009 at 13:02, Yann Leboulanger aste...@lagaule.org wrote: Where could I get network-manager 0.7 dbus specifications? The link on website is broken. Is there a list of specifications diif from 0.6 to 0.7? I have to update my software so it supports network-manager 0.7. Download NetworkManager sources, run configure with '--with-docs' flag and then run make. That'll create the DBus API documentation file docs/spec.html. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM DBus API
On Thu, Jan 1, 2009 at 00:24, Gabriel Joel Perez gabrielj...@gmail.com wrote: Hi! Where can I find the docs for the NM DBus API? Download NetworkManager sources, run configure with '--with-docs' flag and then run make. That'll create the DBus API documentation file docs/spec.html. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: DBus Properties 0.7.0 Device question
On Thu, Dec 18, 2008 at 11:34, Simon Schampijer si...@schampijer.de wrote: Tambet Ingo wrote: On Wed, Dec 17, 2008 at 22:39, Simon Schampijer si...@schampijer.de wrote: Philip Culver wrote: Some addtional information. If I execute: dbus-send --system --dest=org.freedesktop.NetworkManager --print-reply /org/freedesktop/Hal/devices/net_00_13_02_06_6d_ee org.freedesktop.DBus.Properties.Get string:'org.freedesktop.NetworkManager.Device.Wireless' string:'HwAddress' I get the proper value with a Get call. If I execute the GetAll method I always get the generic the Device properties. That is an interesting one. I actually saw the same problem with using the dbus python interface when doing an GetAll on a wired device. It's a bug in dbus-glib. It never even looks at the DBus interface (it only needs to be a string) which is passed to GetAll() method: http://cgit.freedesktop.org/dbus/dbus-glib/tree/dbus/dbus-gobject.c#n1442 Tambet ok, makes sense - Dan was so kind to file it: http://bugs.freedesktop.org/show_bug.cgi?id=19145 I was even kinder, I just fixed it. :) Attached the patch to the bugzilla. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Stop nm-system-settings when NM is stopped
On Wed, Dec 17, 2008 at 15:13, Michael Biebl bi...@debian.org wrote: since NM 0.7 has hit the Debian archive, I got several bug reports, where users changed the configuration in /etc/network/interfaces, restarted NetworkManager (via /etc/init.d/network-manager restart), and wondered, why their changes were not picked up. The reason is, that nm-system-settings keeps running, when you restart the NetworkManager daemon. One obvious answer to this issue, is to monitor /etc/network/interfaces (and /etc/NetworkManager/system-connections/, /etc/NetworkManager/nm-system-settings.conf for that matter) via inotify in the nm-system-settings service. Nonetheless, I think nm-system-settings should stop running, whenever NetworkManager is stopped (just as it is started, whenever NM is started). Now I'm wondering, what the best way is, to do that: Should we just extend the init scripts and add a killall nm-system-settings. Or should nm-system-settings monitor NetworkManager (via D-Bus) and shut down as soon as the org.freedesktop.NetworkManager goes away. Thoughts, Opinions? Technically, NetworkManager doesn't start nm-system-settings daemon (nor wpa_supplicant), so I don't think it should kill it either. It's a DBus activated service and it should have the same life cycle as DBus system daemon. Also, requiring NM/system settings restarts to modify a single NMConnection doesn't sound very nice. So in my opinion, you should just implement monitoring like keyfile,rh, and opensuse plugins do. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] NM 0.7.0 build error
On Tue, Dec 16, 2008 at 01:26, João Valverde backu...@netcabo.pt wrote: Tried the freshly released NetworkManager 0.7.0 tarball (Ubuntu Intrepid i386, stock gcc), I get the following build error: m-netlink-monitor.c cc1: warnings being treated as errors nm-netlink-monitor.c: In function 'nm_netlink_monitor_error_handler': nm-netlink-monitor.c:488: error: format not a string literal and no format arguments Patch: --- NetworkManager-0.7.0/src/nm-netlink-monitor.c 2008-11-25 16:46:39.0 + +++ NetworkManager-0.7.0-1/src/nm-netlink-monitor.c 2008-12-15 23:04:48.0 + @@ -485,7 +485,7 @@ nm_netlink_monitor_error_handler (GIOCha socket_error = g_error_new (NM_NETLINK_MONITOR_ERROR, NM_NETLINK_MONITOR_ERROR_WAITING_FOR_SOCKET_DATA, - err_msg); + %s, err_msg); Using g_error_new_literal() would be a better. Tambet g_signal_emit (G_OBJECT (monitor), signals[ERROR], Regards, João Valverde ___ 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: howto disable default multiple device activation?
On Tue, Nov 25, 2008 at 6:42 PM, Nikolaus Filus [EMAIL PROTECTED] wrote: Tony Espy wrote: What about 3g? Does it also stay connected when an Ethernet cable is plugged in? If so, couldn't that have financial implications to the end-user? Yes, 3g is handled the same way. Modems are different though, they are not activated automatically, so if you remember to activate it when you need it, you should remember to deactivate it as well. Plus, (AFAIK) there's no financial implications when you have the modem activated but not used for any traffic, so in case of active 3g device and ethernet device, all the traffic goes through ethernet device (unless it's specifically to the IP network of your modem). I'm responsible for a little office network and I never saw a use case for connection sharing in office environments. This is also one of those things I disallow for all users. In my eyes only some end users need this for their home networks in rare cases. If you so strongly feel it's bad, then it's your responsibility to pre-configure your office laptops (machines with wifi devices) to have a connection profile for your local wifi network with property connect automatically not set. Besides that I always hated the default windows behaviour of acquiring IP adresses on all interfaces, what means everyone gets 1 ethernet and 1 wireless address. I don't want to have this on linux. Do you have any reasons to hate it, other than I have a gut feeling that this is bad? The fastest device is always used for new TCP connections, so it's not like it'll slow anything down. Here's a specific example why it's good: I'm connected through my wifi device only and have a bunch of open TCP connections (ssh, irc, ...). Then I need to transfer a large file from the local network. I plug in the cable (to make it faster) and start the transfer. When it's done (or whenever I feel like it), I unplug the cable. With 0.6 behavior, I'd need to start my processes 3 times. My point is, there's simply no reason to deactivate the previously active device, it's used until it's necessary and then just stays there until it's needed again. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM and my Vodafone PCMCIA-card doesnt work, NM uses /dev/ttyUSB0 instead of /dev/ttyUSB2
On Sat, Nov 15, 2008 at 3:26 PM, Alexander Sack [EMAIL PROTECTED] wrote: If you are using ubuntu, please file a bug against hal-info package in launchpad with the fixed modem.fdi information. I'm not using ubuntu, but I've seen the same issue reported elsewhere. Does the attached patch fix the issue for you? (Uncompress it to /usr/share/hal/fdi/information/10freedesktop/10-modem.fdi and restart the computer). Tambet 10-modem.fdi.gz Description: GNU Zip compressed data ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM and my Vodafone PCMCIA-card doesnt work, NM uses /dev/ttyUSB0 instead of /dev/ttyUSB2
On Mon, Nov 17, 2008 at 10:48 AM, Knud Müller [EMAIL PROTECTED] wrote: yes! This one works. I made a diff I'll ask a HAL maintainer to include it to upstream. Tambet 32c32 !-- Colt,Ricola,Ricola Light,Ricola Quad,Ricola Quad Light,Ricola Ndis,Ricola Ndis Light, Ricola Ndis Quad,Ricola Ndis Quad Light, --- !-- Colt,Ricola,Ricola Light,Ricola Quad,Ricola Quad Light,Ricola Ndis,Ricola Ndis Light;Ricola Ndis Quad,Ricola Ndis Quad Light, 34c34 Fuji Network Ex,Koi Modem,Koi Network,Scorpion Modem,Scorpion Network,Etna Modem,Etna Network,Etna Modem Lite, Etna Modem Gt, --- Fuji Network Ex,Koi Modem,Koi Network,Scorpion Modem,Scorpion Network,Etna Modem,Etna Network,Etna Modem Lite;Etna Modem Gt, 36c36 match key=@info.parent:usb.product_id int_outof=0x5000;0x6000;0x6100;0x6200;0x6300;0x6050;0x6150;0x6250;0x6350;0x6500;0x6501;0x6600;0x6601;0x6701;0x6711;0x6721;0x6741;0x6761;0x6731;0x6751;0x6771;0x6800;0x6811;0x6901;0x6911;0x7001;0x7021;0x7041;0x7061;0x7031;0x7051;0x7071;0x7100;0x7111 --- match key=@info.parent:usb.product_id int_outof=0x5000;0x6000;0x6100;0x6200;0x6300;0x6050;0x6150;0x6250;0x6350;0x6500;0x6501;0x6600;0x6601;0x6701;0x6711;0x6721;0x6741;0x6761;0x6731;0x6751;0x6771;0x6800;0x6811;0x6901;0x6911;0x7001;0x7011;0x7021;0x7041;0x7061;0x7031;0x7051;0x7071;0x7100;0x7111 42,49d41 match key=@info.parent:usb.product_id int_outof=0x7011 match key=@info.parent:usb.interface.number int=2 append key=modem.command_sets type=strlistGSM-07.07/append append key=modem.command_sets type=strlistGSM-07.05/append /match /match 184c176 !-- PC5740, PC5750, UM150 EVDO rev A card -- --- !-- PC5740;PC5750;UM150 EVDO rev A card -- 227c219 5720 Mobile Broadband CDMA/EVDO Mini-Card == Novatel Expedite E725 CDMA/EV-DO, --- 2x 5720 Mobile Broadband CDMA/EVDO Mini-Card == Novatel Expedite E725 CDMA/EV-DO, 229c221 match key=@info.parent:usb.product_id int_outof=0x8114;0x8117;0x8128;0x8129;0x8133 --- match key=@info.parent:usb.product_id int_outof=0x8114;0x8117;0x8128;0x8129;0x8133;0x8134 354,355c346,347 !-- 6300/3109c/6120 Classic/E71/E70/N95-3/E90/N70/E61/N95-2/N96/N82 -- match key=@info.parent:usb.product_id int_outof=0x4f9;0x64;0x2f;0xab;0x418;0x4f0;0x4ce;0x43a;0x44d;0x070;0x3a;0x72 --- !-- 6300/3109c/6120 Classic/E71/E70/N95-3/E90/N70/E61/E51/N92/N95-2/N96 -- match key=@info.parent:usb.product_id int_outof=0x4f9;0x64;0x2f;0xab;0x418;0x4f0;0x4ce;0x43a;0x44d;0x42;0x72;0x70;0x3a 369c361 match key=@info.parent:usb.product_id int=0x6000 --- match key=@info.parent:usb.product_id int_outof=0x6000 and it simply matches port 2 and port 2 gets the protocol attribute? So my interpretion is that it goes through that cascade for every port. The data port gets the modem protocol information and that is the trigger to use this port by the network-manager? Alexander: where can I post this bug and will they cross check, as other modems occur as well in this passage, that the other products that work differently are not affected by this patch? (I will stress this anyway)? Knud ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 1:41 AM, Slokunshialgo [EMAIL PROTECTED] wrote: I know I posted something about this awhile ago, but thinking about it a bit more, a couple of questions and ideas have arisen in my mind. For those who may not have read this before, the idea is to have something using NetworkManager to automatically log in to web-authenticated networks (ie: hotspots in a cafe) when it connects to specific networks. I have three ideas on how to implement this, but they all revolve around the idea of having a Firefox extension that would listen to dbus signals being sent by nm, and when told to, would go to a specific webpage to log in, using Firefox's password storage. 1) Have nm check to see if Firefox is open, if not, open it and send the signal 2) Make nm have nothing to do with the extension, but merely sending its regular signals and FF picking them up 3) Make nm send modified signals specifically for the autologin, letting any program pick them up (such as network name, URL to visit, etc) Judging by before, I doubt #1 would be the best idea (forcing FF to be installed is not good), #2 may or may not work, but I think #3 would be best. To get around whether FF is open or not, a small program could be written to start on login (separate from nm) that would listen for the signals, start FF, and pass it along. As for the technical side of this, it's primarily, what sort of information does nm send through dbus, and are multiple programs able to pick up on it? Opinions, ideas, information? Add a dispatcher script that runs xdg-open $url for a specific SSID you need it for and you're done. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 4:54 PM, Pablo Martí [EMAIL PROTECTED] wrote: On Tue, Nov 4, 2008 at 3:21 PM, Alexander Sack [EMAIL PROTECTED] wrote: OK thanks for the links. I really think this can be done outside of NM applet to things started. Writing a wispr-applet that listens to D-Bus events from NM and which does the wispr probing and authentication business should be fairly easy. Thanks for the input Alexander, much appreciated. What do other developers think of this approach? Tambet? Dan? I agree it should be done outside of NM. That's the point of having a stable (yeah, yeah, we'll get to that eventually) public DBus API. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
On Tue, Nov 4, 2008 at 11:01 AM, Tomas Kovacik [EMAIL PROTECTED] wrote: and this is HAL .fdi problem?: dmesg: [82410.648181] usb 2-2: new full speed USB device using uhci_hcd and address 2 [82410.821948] usb 2-2: configuration #1 chosen from 1 choice [82411.050542] cdc_acm 2-2:1.1: ttyACM0: USB ACM device [82411.053368] cdc_acm 2-2:1.3: ttyACM1: USB ACM device [82411.055246] usbcore: registered new interface driver cdc_acm [82411.055256] cdc_acm: v0.26:USB Abstract Control Model driver for USB modems and ISDN adapters SE w810i, usb cable No, you don't get HAL logging from dmesg. It's OK to have multiple serial devices per one physical modem, but it's a bug to have 'lshal | grep -i gsm | wc -l' print out higher number than one when you have a single modem. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager API review
On Tue, Nov 4, 2008 at 3:54 AM, Marcel Holtmann [EMAIL PROTECTED] wrote: So the first thing that draw me off is that we are stupidly mapping the HAL devices 1:1 to our devices. That is wrong. We should not do this. So for example my Option card has three TTYs and one network device. This all is one device. Currently it shows up as three devices. The number of TTY (control, data or whatever) is an implementation and should not be exposed via the API. So we have to be smart with this. With the generic implementation, MM maps a HAL device with modem.command_sets property as a single device. So if you got 3, it means your HAL .fdi file is incorrect. The second thing is that the Manager interface talks about devices, while the main interface to the hardware is called Modem. So that should be consistent. Either we call them devices or modems. Agreed. I initially had modems everywhere, but then thought it would be more consistent in the big picture if it resembled org.freedesktop.DeviceKit.Disks (http://hal.freedesktop.org/docs/DeviceKit-disks/) interface. So EnumerateModems was renamed to EnumerateDevices while the modem interfaces didn't change. Just the reason behind it. The Modem interface has a Connect method call that takes a parameter number. This makes no sense whatsoever. Connect should not take any arguments it should connect with whatever has been configured or be smart and auto-configure it. Especially since you don't know if you are using a real number or actually an APN or something else. Modem interface is for all modems. Landline, GSM, CDMA, ... It is up to the specific implementation to validate and use the number. All the modems I've ever seen (and the dial command 'D' in the spec) take a number, so it makes perfect sense to me. And then we have Enable with a parameter. Don't do that. Just add Enable and Disable methods. Otherwise the API looks weird. Also signals like Connected, Enabled etc. are missing. It doesn't look weird to me. In real life you don't have two switches to turn things on/off, and to me it would look weird if my modem has two physical buttons: one to turn it on, and another to turn it off. In short it's a personal opinion and doesn't make much sense to argue about. There is no need for Connected and Enabled signals because the method to Enable/Connect doesn't return before it's done. That does not mean MM is not async, it accepts other commands and is responsive while Enable/Connect/any other method is pending. So the split between Modem interface and Gsm.Card make no real sense to me. I would just convert everything into properties or create a GetProperties method to retrieve one dictionary with all the information. All the GetImei, GetImsi calls only create round-trips to D-Bus that can be avoided. If one technology doesn't have IMSI, then this property is just missing. Again, it's your opinion. In my opinion, when I need IMEI, I don't want the modem to issue 50 AT commands to get all the properties. And for setting things like the APN etc, you can use writable properties or a SetProperty method. So you could just set all properties and then call Connect. To make this fully async, a signal PropertyChanged would be needed, too. So Enable(bool) looks weird to you and then you suggest the whole API to consist of 2 methods (SetStuff() and GetStuff()). Again, your personal opinion I don't agree with. And on that matter, please don't use enums since higher level languages don't really have the concept of includes from a C definition. So if you wanna give the band information you can just say gsm900, gsm1800 etc. Also for the mode having things like connect, connecting etc. make it a lot easier to develop and debug. And when using dbus-monitor is shows up in clear text. Every UI needs to translate enums to localized strings and back so all the possible values need to be defined anyway. It's easier to do it with integers than strings. Some things like GetRegistrationInfo are just better separated into properties or key/value pairs in a dictionary. That keeps the API small and also flexible for future changes. This is something I finally agree on! :) So the network details on GSM are not really that interesting at all. I would leave them out for now. However I do think that representing every network as object path would be a better approach here. Network details and the signal quality are the biggest reason I started ModemManager, the most often asked features in this list. Why would they need to be DBus objects with paths? What methods do you think a network would have? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager Autologin
On Tue, Nov 4, 2008 at 1:00 PM, Alexander Sack [EMAIL PROTECTED] wrote: On Tue, Nov 04, 2008 at 10:44:59AM +0200, Tambet Ingo wrote: Add a dispatcher script that runs xdg-open $url for a specific SSID you need it for and you're done. Do we have per-user dispatcher scripts or are you suggesting to open the browser as root here :) ? Ok, you're right, but listening for a DBus signal from a user process isn't all that hard either. Or do you prefer NM executing firefox directly (as root) like the original mail suggested? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager 99% use CPU
On Mon, Nov 3, 2008 at 3:47 AM, Dan Williams [EMAIL PROTECTED] wrote:
Tambet, maybe the system settings service is getting kicked off the bus
or hanging somewhere in the suse plugin getting unmanaged devices?
Probably. To make it certain, please edit
/etc/NetworkManager/nm-system-settings.conf file, remove the
'ifcfg-suse' (so that the plugins line will become 'plugins=keyfile')
and kill the running system-settings daemon ('killall
nm-system-settings' as root). After doing that, does the
NetworkManager process still consume a lot of CPU?
Tambet
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] mm-modem-mbm.c
On Mon, Oct 27, 2008 at 7:25 PM, bjornrun [EMAIL PROTECTED] wrote: Hope this makes the patch more useful! Thanks! I committed your patch with some minor changes (use spaces instead of tabs everywhere, remove some debug output). Why does the MBM modem not query signal quality while connected? The generic modem code does that because it has ppp connection on the serial port while connected and thus can't issue any AT commands. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Support default path for importing openvpn configuration file
On Tue, Oct 28, 2008 at 11:50 AM, Bin Li [EMAIL PROTECTED] wrote: What's the status of this patch? I just committed it. Thanks! Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATH]: modem-manager: fix for coldstart connect problem + parser hooks for unsolicited msgs
Hey, A couple of comments: * Both new regexps and std_parser are leaked. Dereference them in finalize(). * No need to create an empty callback (msg_waiting), you can just send NULL to mm_util_strip_string(). Thanks, Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Mobile Broadband - how do I trace/debug the modem initialisation?
On Tue, Oct 21, 2008 at 10:47 AM, Craig Main [EMAIL PROTECTED] wrote: I am having a similar issue on my Dell Latitude E6500 which has a Broadcom 5530 buildin hsdpa minicard. This device gives an ERROR when sent an ATZ command. Using a chat script or wvdial with a cusomized wvdial.conf file which leaves out the ATZ command, the modem works flawlessly. When using NetworkManager however it does not. Here is the trace from NetworkManager DEBUG: NetworkManager: info Activation (ttyACM0) starting connection 'Vodacom' NetworkManager: info (ttyACM0): device state change: 3 - 4 NetworkManager: info Activation (ttyACM0) Stage 1 of 5 (Device Prepare) scheduled... NetworkManager: info Activation (ttyACM0) Stage 1 of 5 (Device Prepare) started... NetworkManager: debug [1224572376.061516] nm_serial_device_open(): (ttyACM0) opening device... NetworkManager: info Activation (ttyACM0) Stage 1 of 5 (Device Prepare) complete. NetworkManager: debug [1224572376.169089] nm_serial_debug(): Sending: 'ATZ E0 V1 X4 C1 +FCLASS=0 ' NetworkManager: debug [1224572376.196931] nm_serial_debug(): Got: 'ATZ E0 V1 X4 C1 +FCLASS=0 ' NetworkManager: debug [1224572376.246578] nm_serial_debug(): Got: 'ATZ E0 V1 X4 C1 +FCLASS=0 ERROR ' The init string has more commands than (AT)Z (reset): It turns off echo (E0), sets verbose mode (V1) etc... Can you try to send only ATZ and ATZ E0 V1 to your modem (using minicom or kermit or wvdial) and see if that works? Or if it's specifically Z command that doesn't work, does this command work: ATE1 V1 X4 C1 +FCLASS=0 ? I've seen a device which doesn't like +FCLASS command. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Mobile Broadband - how do I trace/debug the modem initialisation?
On Tue, Oct 21, 2008 at 11:17 AM, Craig Main [EMAIL PROTECTED] wrote: atz ERROR ATE1 V1 X4 C1 +FCLASS=0 OK ATZ E0 V1 ERROR Ah, so it is the reset command, thank you. We've been trying to avoid workarounds for different modems to NetworkManager so unfortunately for now, you'll need to change the init string in the code and recompile NM. I am working on another code base which has plugins (sort of drivers) to allow special handling of non-standard modems. I'd like to add support for your modem, can you please send me the output of 'lshal' (either privately or to list)? Thanks ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Mobile Broadband - how do I trace/debug the modem initialisation?
On Tue, Oct 21, 2008 at 11:50 AM, Stuart Ward [EMAIL PROTECTED] wrote: The issue is that you have enabled unsolicited response codes. Several possable solutions 1) add +CREG=0 to your init string to disable. 2) perhaps nm should be able to parse the response string and match it to a regex expression rather than a fixed string. What is important is the the modem is registered to a network so a response of 1 or 5 would be valid What? The issue is that there's a modem that does not like 'Z' (reset) command. It has nothing to do with +CREG or unsolicited response codes. We're talking about modem initialization, registration comes way later _after_ modem is initialized. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Mobile Broadband - how do I trace/debug the modem initialisation?
On Tue, Oct 21, 2008 at 12:14 PM, Per Hallsmark [EMAIL PROTECTED] wrote: Yes, this is definitly a modem that falls into the mbm plugin. I've submitted a patch for it earlier to this list, although that one requires another NetworkManager patch (changing a bit how iface/ip_iface is used) as well as a driver which unfortunally isn't submitted yet (but will hopefully be in the nearest days!) I committed your patches from last week yesterday. Tambet, what about the plugins beeing able to specify a init string and close string? (if the standard wont work that is) Yeah, it's probably a good idea. Overriding the whole Enable() is a bit too much work if you only need to use a different init string. I'll have that later today. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Mobile Broadband - how do I trace/debug the modem initialisation?
On Sat, Oct 18, 2008 at 2:59 PM, Rick Jones [EMAIL PROTECTED] wrote: Where are the actual dialling protocol exchanges defined - are they hard-coded? Not being able to script this bit of the connection seems to be problematic, compared to pppd. I'd really like to move to NM instead of messing with pppd, pon, poff etc. but I can't get past the first hurdle :( If you have recent enough NM (r4155 or newer), you can turn on serial debug with NM_SERIAL_DEBUG environment variable. The AT commands are hard coded and there are no plans to leave it to users to figure out. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Two networks with the same SSID
On Sun, Oct 12, 2008 at 8:31 PM, Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote: There are two networks with the same SSID around here I suppose. The symptoms: sometimes I have no problems connecting to the network, but sometimes network-manager tries to connect and then asks for the keys, and in such case it is virtually impossible to connect even after many tries — unless I come physically close to the wireless router, in which case the connection has a high chance to succeed. In any case, when eventually connected, the connection works fine from the first location as well; it does not drop, and does not stall. dmesg shows different AP macs in the successful and unsuccessful case, even though nm always shows a single network with this name. Is it possible to specify the connection in nm such that it always chooses the right network? I tried to specify a MAC in the connection dialog (I am not sure whether this is supposed to be my the network card mac or the AP mac), but then nm does not connect to such network and creates another connection when I choose the network from the applet. The BSSID entry is what you need to use. See the tooltips of text entry widgets to get more information what MAC and BSSID fields do. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: UMTS status
On Mon, Oct 13, 2008 at 5:29 AM, Dan Williams [EMAIL PROTECTED] wrote: On Fri, 2008-10-10 at 17:23 +0200, Cyril Jaquier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm wondering if it would be possible to add some kind of signal strength/quality while connected to an GSM/UMTS network. I know umtsmon displays such information but I don't know if there is a standard way to get them. Yes, after 0.7 comes out. The issue is that different cards use different methods, and for other cards we can't get the signal strength out of them at all (single-port cards mainly). But it will happen. Or, if you want to see the future today, check out ModemManager (http://gitorious.org/projects/modemmanager). The checkout contains patches to make NetworkManager and nm-applet use it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: default route problem
On Mon, Oct 6, 2008 at 5:39 PM, Trey Nolen [EMAIL PROTECTED] wrote: On this same topic, Network Manager also removes any NON default routes that you have. I personally sometimes set different routes up for the internal network. These are NOT given out by DHCP, but when you connect/disconnect a VPN, those routes are blown away. I would LOVE for this to be addressed. You CAN go to the connection editor and ADD static routes to your connection. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: default route problem
On Wed, Oct 8, 2008 at 3:04 PM, Trey Nolen [EMAIL PROTECTED] wrote: But, if you do, you can't use any VPNs. At least when I try it, all my VPNs go away. If you have a method that works, please describe how. What I already suggested is how it is supposed to work. If not, we'll need to fix it, not implement some other (broken) functionality. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Support for bonding?
On Sun, Sep 28, 2008 at 9:49 PM, David Abrahams [EMAIL PROTECTED] wrote: Has any thought been given to supporting a setup like the one described here: http://www.debian-administration.org/articles/312#comment_9 ? I googled up that post when thinking about how to retain connectivity when moving from wired to wireless and vice-versa. I'm happy to do the configuration manually (although someone clearly wants NM to handle it: http://brainstorm.ubuntu.com/idea/10534/) but it seems at least likely that NM might interfere. If that's not the case, so much the better; I'll try to set it up and see what happens. Regardless, allowing people to dock/undock or plug-in/roam without interrupting their connections seems like it's right up NM's alley. I have been thinking about supporting bonding in NetworkManager (personally, I'd _love_ to have it), some people even argue that the current multiple device support does not make sense without bonding. There's an issue though with using bonding with wpa_supplicant (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483207 , http://hostap.epitest.fi/bugz/show_bug.cgi?id=270) so that needs to get solved first. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, Sep 30, 2008 at 11:19 AM, Pablo Martí [EMAIL PROTECTED] wrote: I think that Network.NetworkMode's enum has some values that should be changed to something more realistic. The devices I have around (Option and Huawei mainly) won't emit an 'ANY' signal, neither a 'PREFER_2G', ditto with 'PREFER_3G'. I propose to change it to: MM_MODEM_GSM_NETWORK_MODE_NO = 0 # NO SIGNAL MM_MODEM_GSM_NETWORK_MODE_GPRS = 1 MM_MODEM_GSM_NETWORK_MODE_EDGE = 2 MM_MODEM_GSM_NETWORK_MODE_3G = 3 MM_MODEM_GSM_NETWORK_MODE_HSDPA = 4 MM_MODEM_GSM_NETWORK_MODE_HSUPA = 5 MM_MODEM_GSM_NETWORK_MODE_HSPA = 6 If the last three members seem to much info they could be marged into a 3G+ although I prefer granularity and exactness :) No, but the argument type passed with the signal is not an integer, it's NM_MODEM_GSM_NETWORK_MODE. That is, the same type that is used for setting the network mode. And thus, that type needs all these values. There is also no need to add another type which is just like NETWORK_MODE, but doesn't include some of it's values. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, Sep 30, 2008 at 2:46 PM, Pablo Martí [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 1:31 PM, Tambet Ingo [EMAIL PROTECTED] wrote: No, but the argument type passed with the signal is not an integer, it's NM_MODEM_GSM_NETWORK_MODE. That is, the same type that is used for setting the network mode. And thus, that type needs all these values. There is also no need to add another type which is just like NETWORK_MODE, but doesn't include some of it's values. Oh yeah true. How about adding NO_SIGNAL, HSUPA and HSPA too? Dan already notified me that I'm missing HSPA. He also said we don't need HSUPA for some reason (I don't remember why, Dan?). In which case would you need to send a NetworkMode changed signal with NO_SIGNAL argument? I must be misunderstanding something as I'd just not emit the signal in that case? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: org.freedesktop.ModemManager.Modem.Gsm.Network.NetworkMode signal
On Tue, Sep 30, 2008 at 3:25 PM, Pablo Martí [EMAIL PROTECTED] wrote: Option and Huawei devices emit that signal usually upon a SetNetworkMode command. They'll temporally be in NO_SIGNAL and then emit whatever mode they've switched to. Also that signal might be emitted on scenarios where you specify 3GONLY and there's just 2G coverage. Ok, I finally did understand it, thanks. I'll add it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connecting vpn server failed with not allowed to own the service
On Fri, Sep 26, 2008 at 6:37 AM, Bin Li [EMAIL PROTECTED] wrote: When I build the plugin and make install it, sometimes it prompt below info when I connecting the VPN server. ** (process:5919): WARNING **: WARN constructor(): Connection :1.9266 is not allowed to own the service org.freedesktop.NetworkManager.openvpn due to security policies in the configuration file ** (process:5919): CRITICAL **: ERROR [1222400073.796200] main (): Create new openvpn_plugin failed! Why this happen? And in normal it's no this issue. How to resolve it? I just restart the dbus, but the dbus affects a lot of other process. It's a DBus problem, sometimes when you change the content of /etc/dbus-1/system.d/ it'll loose it's configuration. Send the HUP signal to DBus to make it re-read the configuration. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-connection-editor crash when adding or deleting vpn connection
On Tue, Sep 23, 2008 at 9:26 PM, Dan Williams [EMAIL PROTECTED] wrote: On Tue, 2008-09-23 at 18:22 +0300, Tambet Ingo wrote: Attached. Some good person should add Show passwords checkboxes to all the openvpn connection method tabs too. :) Thanks, please commit. Committed. I also was the good person and added Show passwords checkbox. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm-connection-editor crash when adding or deleting vpn connection
On Tue, Sep 23, 2008 at 5:51 AM, Bin Li [EMAIL PROTECTED] wrote: Yes, I've update the NM r4088 and applet r899, when I adding the openvpn configuration in nm-connection-editor, it same issue. And start again nm-connection-editor, you could found the configuration already be added. When you delete this configuration, it prompt: ** (nm-applet:24554): WARNING **: nma_gconf_connection_changed: Invalid connection /system/networking/connections/10: 'NMSettingIP4Config' / 'method' invalid: 2 Segmentation fault The warning isn't directly related to the crash. It crashes because openvpn plugin does not implement delete_connection and save_secrets methods. It would be an easy fix to just not make it crash, but while looking into it, I remembered something else I had meant to take care of: openvpn properties page does not have any way of setting passwords. I'm on it and will post a patch later today. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] rename resolv.conf.tmp failed.
On Tue, Sep 16, 2008 at 10:13 AM, Bin Li [EMAIL PROTECTED] wrote: When network connecting success, dispatch_netconfig() processed failed for not having the /sbin/netconfig in openSUSE 11.0, then fill the 'error' info like this: Failed to execute child process /sbin/netconfig (No such file or directory)' netconfig is for openSUSE 11.0. When called the update_resolv_conf(), before rename(), the 'error' already be set by dispatch_netconfig(), so if (*error == NULL) failed, so not rename the resolv.conf.tmp to resolv.conf. In my patch, using local variable used for checking error occurring. It works fine, but I'm not sure if it's suitable or not, feel free to change it. Not sure if we should care. Basically, suse has policies to not upgrade released software, only to apply patches for security issues and major bugs (crashers). So your patch will never be used. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connecting with wpa_supplicant works, NM 0.7 doesn't
On Wed, Sep 17, 2008 at 12:42 PM, Giovanni Lovato [EMAIL PROTECTED] wrote: I tried to hack gconf keys to set that peaplabel=0 but every time I connect gconf keys are regenerated and the string I added unset. Don't know if that string is important, but I guess it is since without it wpa_supplicant won't connect. Try with key phase1-peaplabel and value 0 (string). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
Hey, Just a general update, ModemManager from http://gitorious.org/projects/modemmanager implements the API we've agreed on so far. It also contains patches to make NetworkManager and nm-applet use ModemManager (the http://svn.gnome.org/viewvc/NetworkManager/branches/modem-manager/ branch is not used anymore, I found it too annoying to keep it in sync with trunk). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Fri, Aug 29, 2008 at 2:37 PM, Roberto Majadas [EMAIL PROTECTED] wrote: The api extension proposed by Pablo looks very nice. But probably we need to add many methods to this proponsal. Could be very interesting for all of us open a live.gnome.org wiki page and write the interfaces/methods together. Could you please give me some examples what we're still missing? I'd rather do the API changes over mail, so that everyone can easily comment the changes. I don't think wiki is good for that, there's no place to explain why changes have been made. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Thu, Aug 28, 2008 at 10:48 AM, Pablo Martí [EMAIL PROTECTED] wrote: It seems that there's already some consensus, why don't you create a wiki page for all this and the interested parties finish the spec there? Yes, good idea. Wiki page is probably not the best format thought, since I'd like to have the HTML automatically generated from the real specifications. Not sure how to publish it. For now, it's attached. To generate HTML, simply run 'make'. Tambet modem-manager-spec.tar.gz Description: GNU Zip compressed data ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Thu, Aug 28, 2008 at 12:21 PM, Tambet Ingo [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 10:48 AM, Pablo Martí [EMAIL PROTECTED] wrote: It seems that there's already some consensus, why don't you create a wiki page for all this and the interested parties finish the spec there? Yes, good idea. Wiki page is probably not the best format thought, since I'd like to have the HTML automatically generated from the real specifications. Not sure how to publish it. For now, it's attached. To generate HTML, simply run 'make'. Pablo Martí found some small stylistic problems (GetIMEI and GetIMSI vs GetSmsc), which are fixed now (GetImei, GetImsi, GetSmsc). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Wed, Aug 27, 2008 at 6:17 PM, Pablo Martí [EMAIL PROTECTED] wrote: org.freedesktop.ModemManager.Modem.Gsm.Network: - GetRegistrationStatus() - (uu)(AT+CREG?) - GetInfo() - (su) (AT+COPS?) - GetNames() - a(ussuu) (AT+COPS=?) - GetRoamingIDs() - as(AT+CPOL?) - GetSignalQuality() - u - SetRegistrationNotification(b enable) - - SetInfoFormat(u mode, u format) - (i.e. AT+COPS=3,0) - RegisterWithNetID(s netid) - - CregReceived(u status) - (signal) - SignalQuality(u rssi) - (signal) I think these are too low level. I'd much prefer the current ones from ModemManager. You mean: - Register() - Tries to register with your home network - Register(24301) - Tries to register with the given MNC I can agree in this two. AT+COPS? is a pretty useful command that you've (inadvertently) banned here :), ditto with At+COPS=? and AT+CPOL? when you have a buggy firmware/old SIM that does strange things while roaming... I also meant: GetRegistrationInfo() - (uss) The returned arguments mean: u - Registration status: Idle:Home:Searching:Denied:Unknown:Roaming s - Registered operator code s - Registered operator long name Which would be the union of a lot of commands you proposed. org.freedesktop.ModemManager.Modem.Gsm.PIN: - Change(s oldpin, s newpin) - - Check() - u (Returns the SIM auth state, to check it against an enum) - Enable(s pin) - - Disable(s pin) - - Send(s pin) - - SendPUK(s puk, s pin) - Not sure about these. Currently, Check() is part of Gsm.Card.Enable(True). Enable(pin)/Disable(pin) could be one method with a boolean argument. What's the difference (code wise) between Send() and SendPUK()? So that would leave us with 3 methods: Enable(bool), Send(string), Change(string, string). If so, maybe they can be part of the Gsm.Card interface? Enable(b) sounds good to me. The difference between Send and SendPUK is that the former receives just one parameter (the pin), while the later receives two, the puk and the new PIN to set in the card. One of the advantages of having a separate interface is that CDMA devices cant just skip the .PIN interface. Otherwise they'll support half of .Card. We're talking about the interfaces starting with org.freedesktop.ModemManager.Gsm.* so CDMA can be ignored here. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Wed, Aug 27, 2008 at 6:17 PM, Pablo Martí [EMAIL PROTECTED] wrote: I can agree in this two. AT+COPS? is a pretty useful command that you've (inadvertently) banned here :), ditto with At+COPS=? and AT+CPOL? when you have a buggy firmware/old SIM that does strange things while roaming... Sorry, forgot to comment part of it: All the buggy firmware and whatever other workarounds need to be hidden behind this API, not exposed and delegated. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bug in resolv.conf rewrite
On Fri, Aug 15, 2008 at 4:55 PM, Miner, Jonathan W (US SSA) [EMAIL PROTECTED] wrote: I may have found a bug in the resolv.conf rewriting code. Here is the scenario that caused this: 1) Booted up with wireless network, ISP #1. I didn't verify, but the file should have contained: nameserver A.B.C.35 nameserver A.B.C.36 2) Connected to physical ethernet, ISP #2. The contents of /etc/resolv.conf now has, with names obscured in CAPS # generated by NetworkManager, do not edit! DOMAIN.NAME.COMPANY.COM.search DOMAIN.NAME.COMPANY.COM. nameserver X.Y.26.118 nameserver X.Y.12.27 nameserver A.B.C.35 # NOTE: the glibc resolver does not support more than 3 nameservers. # The nameservers listed below may not be recognized. nameserver A.B.C.36 The search line is broken. Yes, I accidentally made a typo with that commit, but Dan fixed it on August 12th, r3943. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: An Idea
On Wed, Aug 13, 2008 at 2:15 AM, Hasan Ceylan [EMAIL PROTECTED] wrote: snip Now, then the dynamic hosts file idea came on my mind. Wouldn't it be nice to have some hosts definitions in the connection properties so that they become effective based on the connection just like the IP and DNS setting based on connection profile in Network Manager This can (and should) be done easily with dispatcher scripts. There's a lot of things that might need to be changed depending on location (things like printers, browser proxies, SMTP server, firewall, ...) and NM should not try to do everything. Instead, it should provide an easy way to add hooks and that's what the dispatcher is for. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wha is ipv4 prefix?? (why not netmask)
On Fri, Aug 8, 2008 at 5:56 PM, Dan Williams [EMAIL PROTECTED] wrote: On Thu, 2008-08-07 at 19:11 -0400, Nathaniel McCallum wrote: Derek Atkins wrote: Miguel Angel Cañedo [EMAIL PROTECTED] writes: I was pulling my hair trying to set static ipv4 settings. Until I realized that NM 0.7 asks for PREFIX instead of NETMASK Now, my netmask should be 255.255.0.0 How do I transalte that into the Prefix? /16 ? I also thought the wording was less-than-clear. We should really be accepting a netmask in that field and autoconverting to a prefix when you hit tab or move out of the field. There are quite a few rough edges to the connection editor that we do need to fix up. One less rough edge, I renamed the column header to Netmask (from Prefix) and the column now accepts both prefix length and netmask. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] resolv.conf updating
Hey,
There's been quite a few discussions on how to update resolv.conf on
debian. Now that opensuse is also moving to a script to update
resolv.conf, I wrote a patch for NM to allow distro specific methods
for updating. It defaults to writing out manually (all distros except
opensuse for now), but should give a good example how to add a debian
specific workaround.
The other patch just removes the unused (and broken by design)
should_update_resolv_conf.
Tambet
From 029c0b6fc59721a79a5df571c243b405162afad0 Mon Sep 17 00:00:00 2001
From: Tambet Ingo [EMAIL PROTECTED]
Date: Mon, 11 Aug 2008 12:44:18 +0300
Subject: [PATCH] resolv.conf updating rework.
diff --git a/src/NetworkManagerPolicy.c b/src/NetworkManagerPolicy.c
index 631068f..ea5d5e1 100644
--- a/src/NetworkManagerPolicy.c
+++ b/src/NetworkManagerPolicy.c
@@ -122,7 +122,6 @@ update_routing_and_dns (NMPolicy *policy, gboolean force_update)
NMActRequest *best_req = NULL;
GSList *devices, *iter;
NMNamedManager *named_mgr;
- NMIP4Config *config;
devices = nm_manager_get_devices (policy-manager);
for (iter = devices; iter; iter = g_slist_next (iter)) {
@@ -196,8 +195,10 @@ update_routing_and_dns (NMPolicy *policy, gboolean force_update)
}
named_mgr = nm_named_manager_get ();
- config = nm_device_get_ip4_config (best);
- nm_named_manager_add_ip4_config (named_mgr, config, NM_NAMED_IP_CONFIG_TYPE_BEST_DEVICE);
+ nm_named_manager_add_ip4_config (named_mgr,
+ nm_device_get_ip_iface (best),
+ nm_device_get_ip4_config (best),
+ NM_NAMED_IP_CONFIG_TYPE_BEST_DEVICE);
g_object_unref (named_mgr);
/* Now set new default active connection _after_ updating DNS info, so that
diff --git a/src/NetworkManagerSystem.c b/src/NetworkManagerSystem.c
index bf6b11d..5793963 100644
--- a/src/NetworkManagerSystem.c
+++ b/src/NetworkManagerSystem.c
@@ -385,7 +385,7 @@ nm_system_vpn_device_set_from_ip4_config (NMDevice *active_device,
out:
named_mgr = nm_named_manager_get ();
- nm_named_manager_add_ip4_config (named_mgr, config, NM_NAMED_IP_CONFIG_TYPE_VPN);
+ nm_named_manager_add_ip4_config (named_mgr, iface, config, NM_NAMED_IP_CONFIG_TYPE_VPN);
g_object_unref (named_mgr);
return TRUE;
@@ -406,7 +406,7 @@ gboolean nm_system_vpn_device_unset_from_ip4_config (NMDevice *active_device, co
g_return_val_if_fail (config != NULL, FALSE);
named_mgr = nm_named_manager_get ();
- nm_named_manager_remove_ip4_config (named_mgr, config);
+ nm_named_manager_remove_ip4_config (named_mgr, iface, config);
g_object_unref (named_mgr);
return TRUE;
diff --git a/src/named-manager/nm-named-manager.c b/src/named-manager/nm-named-manager.c
index 0162ea9..dc4a0b9 100644
--- a/src/named-manager/nm-named-manager.c
+++ b/src/named-manager/nm-named-manager.c
@@ -1,3 +1,5 @@
+/* -*- Mode: C; tab-width: 5; indent-tabs-mode: t; c-basic-offset: 5 -*- */
+
/*
* Copyright (C) 2004 - 2008 Red Hat, Inc.
*
@@ -26,6 +28,8 @@
#include stdlib.h
#include errno.h
#include arpa/inet.h
+#include sys/types.h
+#include unistd.h
#include glib.h
#include glib/gi18n.h
@@ -85,50 +89,6 @@ nm_named_manager_error_quark (void)
return quark;
}
-static char *
-compute_nameservers (NMIP4Config *config)
-{
- int i, num;
- GString *str = NULL;
-
- g_return_val_if_fail (config != NULL, NULL);
-
- num = nm_ip4_config_get_num_nameservers (config);
- if (num == 0)
- return NULL;
-
- str = g_string_new ();
- for (i = 0; i num; i++) {
- #define ADDR_BUF_LEN 50
- struct in_addr addr;
- char *buf;
-
- addr.s_addr = nm_ip4_config_get_nameserver (config, i);
- buf = g_malloc0 (ADDR_BUF_LEN);
- if (!buf)
- continue;
-
- if (!inet_ntop (AF_INET, addr, buf, ADDR_BUF_LEN))
- nm_warning (%s: error converting IP4 address 0x%X,
- __func__, ntohl (addr.s_addr));
-
- if (i == 3) {
- g_string_append (str, \n# );
- g_string_append (str, _(NOTE: the glibc resolver does not support more than 3 nameservers.));
- g_string_append (str, \n# );
- g_string_append (str, _(The nameservers listed below may not be recognized.));
- g_string_append_c (str, '\n');
- }
-
- g_string_append (str, nameserver );
- g_string_append (str, buf);
- g_string_append_c (str, '\n');
- g_free (buf);
- }
-
- return g_string_free (str, FALSE);
-}
-
static void
merge_one_ip4_config (NMIP4Config *dst, NMIP4Config *src)
{
@@ -155,49 +115,221 @@ merge_one_ip4_config (NMIP4Config *dst, NMIP4Config *src)
}
}
+#if defined(TARGET_SUSE)
+/**/
+/* SUSE */
+
+static void
+netconfig_child_setup (gpointer user_data G_GNUC_UNUSED)
+{
+ pid_t pid = getpid ();
+ setpgid (pid, pid);
+}
+
+static gint
+run_netconfig (GError **error)
+{
+ GPtrArray *argv;
+ gint stdin_fd;
+
+ argv = g_ptr_array_new ();
+ g_ptr_array_add (argv, /sbin/netconfig);
+ g_ptr_array_add (argv, modify);
+ g_ptr_array_add (argv, --service);
+ g_ptr_array_add (argv, NetworkManager);
+ g_ptr_array_add (argv, NULL);
+
+ if (!g_spawn_async_with_pipes (NULL, (char
Re: Network Manager fails to connect to a network when a static IP is in use
On Fri, Aug 1, 2008 at 8:34 PM, Sebastian [EMAIL PROTECTED] wrote: Bad news: Name: NetworkManager Version: 0.7.0.r3685-7.1 Arch: i586 It looks like my NM 0.7 does not handle static IP correctly. Do you think it can be an openSUSE problem? Do you recommend me letting openSUSE team know about that? Can you please provide the information I asked for? I am the opensuse NM maintainer, I can't help you if you don't provide more info than it doesn't work. It does work for me. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Fri, Aug 1, 2008 at 8:59 AM, Helmut Schaa [EMAIL PROTECTED] wrote: Which changes will be needed for NM frontends? Are there any drastic API changes or do the settings need refactoring? First of all, this all will happen after 0.7 release. There are no NetworkManager API changes, but we'll need to add new methods and signals to the modem devices to use the new functionality. The settings already contain all the required fields (some of which are currently not used by NM). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Fri, Aug 1, 2008 at 12:30 AM, Roberto Majadas [EMAIL PROTECTED] wrote: I'm Roberto Majadas (mobile-manager developer). I was reading your spec about modem-manager. It's really interesting but i think you are trying to implement the same thing that we've implementated. Mobile Manager has a public and documentated Dbus API[1]. It support many features like pin/puk management, device and status information, plug play support, device plugin system At the moment we support this devices : - Huawei - Option - Nozomi - Sierra - Novatel - Usb devices - Bluetooth devices And in the future we'll support more devices. About the programming language that should be written a daemon. Yeah C it's a good option in fact (i'm C programmer). But there are many, many, many situations easier to resolve using python in this case. The GPRS/3G devices sometimes are evils ;), belive me, i was working on it the last two years :). In this way MobileManager only depends of python, python-dbus and python-gobject (5-10Mb in memory) At the moment we use wdial to establish the ppp connection but we can change it and use NM ppp system. We are open to talk everything and we are open to colaborate ;) Again, all this work has been done to support other modem driving solutions (like mobile-manager). There were two missing pieces: It wasn't possible to use other languages than C before, which is solved by writing code to NetworkManager to talk to modems over dbus. Another thing that was missing was the dbus API. Now that is defined as well (but is open for changes). There are other (from mobile-manager) interested parties and everyone has their own API. NM shouldn't try to implement all of them, so we needed to define something that everyone can target. ModemManager that I just announced is just one implementer. As you say, it takes time to write a good one, and using existing programs (which need to adapt the API changes, or just provide another set of API to be integrated with NM) we have a complete solution today. The way to collaborate (to integrate with NM) is to try to implement the API I've defined, and give me feedback on what should change there. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
It looks like I did terrible job explaining _why_ I wrote ModemManager. Let me try again. Where were we before ModemManager. The current state in NetworkManager 0.7 is that we have the absolute minimum support for modems to claim that we support modems. There are a couple of advanced solution out there (mobile-manager, vmc, umtsmon) that do much better job and have many more features. Multiple people contacted us asking if we could integrate their solution, each with different API. How to solve that? Given that the existing mobile applications were written in other languages than C, it became clear we need an out of process design for modems. So DBus was chosen. The next obstacle is that each existing solution has it's own API. The solution I chose for this is to define a common API that NetworkManager uses and any project that wants to be integrated, can implement two simple interfaces. I felt it was a better choice than using any of the existing APIs to not make anyone feel left out. Why did I write ModemManager? I'm no a genius and can't define API without trying to use it. Therefore, I needed something to test on. ModemManager is very little apart from the newly defined DBus interface plus the modem handling code from NetworkManager. So it's not like I've made huge investments trying to reimplement a wheel (or existing projects). Where are we now? I wrote the code for NetworkManager to support out of processes modem handling API. It's in 'ModemManager' branch in the NetworkManager's SVN tree. We have a clear answer to any project that wants to integrate with NetworkManager. Do I keep working on ModemManager? Yes. As long as existing solution can be used with NetworkManager, I feel like I've solved the main goal. If my pet project doesn't succeed, there's no great loss. If it does, it gives me (and possibly others) more choice. If there are two backends, one written in python and one in C and both do the job for me, I'd choose the C one. Other people, depending on their specific hardware, beliefs or what not, might choose the other. Does it make sense? Tambet On Thu, Jul 31, 2008 at 6:10 PM, Tambet Ingo [EMAIL PROTECTED] wrote: Announcing ModemManager. It's a standalone DBus system service to provide a common API to communicate with broadband modems. It is derived from the modem handling code from NetworkManager and in addition to DBus API, it adds more operations (scanning, signal quality, changing network mode, band, ...). It is easy to extend by having a plugin system to provide drivers for non standard operations. There is currently one plugin implemented for Huawei cards. It's fully functional and can be used as an example to write plugins for other cards (hint! hint!). Some QA Q: Where can I get it? A: git clone git://gitorious.org/modemmanager/mainline.git modemmanager Q: What does it have to do with NetworkManager? A: NetworkManager will use ModemManager instead of current basic code in the future. Q: Can I see it in action? A: Yes! I've ported NM to use it already, but haven't exposed any of the new functionality in the UI. The fully working branch can be downloaded from the NetworkManager SVN branch: svn co svn+ssh://[EMAIL PROTECTED]/svn/NetworkManager/branches/modem-manager NetworkManager-mm [or using anonymous svn] svn co http://svn.gnome.org/svn/NetworkManage/branches/modem-manager NetworkManager-mm Q: Why? A: There have been some requests to integrate some existing mobile programs with NM (vodafone, telefonica) and it's never been easier: All that needs to happen is to implement the same public DBus API and NM will use that instead. A2: The current modem handling code in NM is very basic, and supporting non standard operations and cards is pretty much impossible without total reorganization. Well, ModemManager is the reorganization. Q: You lied, it doesn't support signal monitoring while connected! A: No, it just means it's a non standard feature and needs a card specific plugin which isn't written for your card yet. Q: Is there any documentation available for it? A: Yes, pass a --with-docs argument to the configure and it'll create docs/spec.html which is the DBus API reference. There's also some information in the README file. Q: Can I write a plugin for my own card? A: Yes! Take a look at plugins/ directory to see the Huawei plugin, it should be pretty easy to write new ones based on that. Q: I think I've found a bug. A: Great! let me (tambet /at/ gmail.com for now) know. Extra points if you can provide a patch! Q: You API sucks! A: If there's something you'd like to change, either to add new methods or to modify the existing ones, let me know, it's not set in the stone. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Network Manager fails to connect to a network when a static IP is in use
On Fri, Aug 1, 2008 at 1:18 PM, Sebastian [EMAIL PROTECTED] wrote: The laptop needs a static IP in order to have access to a fileserver. When I try to configure static IP address with a help of Gnome Network Manager Applet, I cannot connect to the network then. It looks like the Network Manager fails to write a proper DNS address into resolv file. To be more specific, the file it writes is empty. Could you please be more specific describing how you did that? Could you try to create a new connection, fill in all the information there and make a note of each step? Also, please attach the NM log file (/var/log/NetworkManager) of the time when you try to activate the newly created connection and fails to produce usable /etc/resolv.conf. The same happens when I try to configure static IP address via Yast. Static IP configuration from yast is in a terrible state. The main cause of this is that when you configure DNS information in yast, it only saves it in /etc/resolv.conf. That means that if you use NM with DHCP on any device, the information filled with yast is lost forever. There are hacky work arounds to make it possible, but if you use NetworkManager on suse, I'd suggest to remove all the network device configuration in yast and use NM exclusively. (and yes, we are trying to improve the situation). It is also very annoying that it takes several second for the Network Manager to connect to a network. It is very sad because previous version of the Netwok Manager seems to connect much faster to the same network. This is more likely caused by the new driver for your card (opensuse 10.3 had a different driver from 11.0). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[ANNOUNCE] ModemManager (for GSM and CDMA)
Announcing ModemManager. It's a standalone DBus system service to provide a common API to communicate with broadband modems. It is derived from the modem handling code from NetworkManager and in addition to DBus API, it adds more operations (scanning, signal quality, changing network mode, band, ...). It is easy to extend by having a plugin system to provide drivers for non standard operations. There is currently one plugin implemented for Huawei cards. It's fully functional and can be used as an example to write plugins for other cards (hint! hint!). Some QA Q: Where can I get it? A: git clone git://gitorious.org/modemmanager/mainline.git modemmanager Q: What does it have to do with NetworkManager? A: NetworkManager will use ModemManager instead of current basic code in the future. Q: Can I see it in action? A: Yes! I've ported NM to use it already, but haven't exposed any of the new functionality in the UI. The fully working branch can be downloaded from the NetworkManager SVN branch: svn co svn+ssh://[EMAIL PROTECTED]/svn/NetworkManager/branches/modem-manager NetworkManager-mm [or using anonymous svn] svn co http://svn.gnome.org/svn/NetworkManage/branches/modem-manager NetworkManager-mm Q: Why? A: There have been some requests to integrate some existing mobile programs with NM (vodafone, telefonica) and it's never been easier: All that needs to happen is to implement the same public DBus API and NM will use that instead. A2: The current modem handling code in NM is very basic, and supporting non standard operations and cards is pretty much impossible without total reorganization. Well, ModemManager is the reorganization. Q: You lied, it doesn't support signal monitoring while connected! A: No, it just means it's a non standard feature and needs a card specific plugin which isn't written for your card yet. Q: Is there any documentation available for it? A: Yes, pass a --with-docs argument to the configure and it'll create docs/spec.html which is the DBus API reference. There's also some information in the README file. Q: Can I write a plugin for my own card? A: Yes! Take a look at plugins/ directory to see the Huawei plugin, it should be pretty easy to write new ones based on that. Q: I think I've found a bug. A: Great! let me (tambet /at/ gmail.com for now) know. Extra points if you can provide a patch! Q: You API sucks! A: If there's something you'd like to change, either to add new methods or to modify the existing ones, let me know, it's not set in the stone. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Thu, Jul 31, 2008 at 6:23 PM, Carlos Perelló Marín [EMAIL PROTECTED] wrote: Is nice to see this kind of software popping up :-) Are you in touch with the guys behind mobilemanager (http://mobilemanager.movilforum.com/)? They sent an announcement about a DBUS system like ModemManager a couple of months ago. They are part of Telefonica, and that's the movement they did to integrate their software with Network Manager. Yes, I know. That's the main reason why we'll be moving to the out of process DBus service. NM can't support all modem DBus service implementations out there and this work has partly been for defining a common API. With the SVN branch of NM I posted, it would be very easy to integrate whoever might be interested in doing so. For the longer term, my personal opinion is that system daemons should be written in C (but it's a matter of opinion, and with out of process implementation, it's easy to disagree and use something else). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: wha is ipv4 prefix?? (why not netmask)
Hey, On Fri, Aug 1, 2008 at 1:44 AM, Miguel Angel Cañedo [EMAIL PROTECTED] wrote: I was pulling my hair trying to set static ipv4 settings. Until I realized that NM 0.7 asks for PREFIX instead of NETMASK Now, my netmask should be 255.255.0.0 How do I transalte that into the Prefix? 16. What is that prefix thing? This should help (from google cache): http://209.85.135.104/search?q=cache:N2B0npwBLb4J:www.gadgetwiz.com/network/netmask.html The netmask entry should probably autodetect whether the entered value is a prefix or netmask. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Troubles at 3G paradise
On Thu, Jul 24, 2008 at 2:47 PM, André Lemos [EMAIL PROTECTED] wrote: Jul 24 12:24:23 lapy NetworkManager: debug [1216898663.617076] serial_debug(): Sending: 'ATD*99***1***1# ' Jul 24 12:24:23 lapy NetworkManager: debug [1216898663.634862] serial_debug(): Got: ' ERROR ' Any hints on this? This happens with revision 3846. I am not a big expert, but the number should be *99***1#. Is the rest of it ***1# part of the protocol? By changing: //g_string_append_printf (str, ***%d#, cid); g_string_append_printf (str, #); on line 185 on the src/nm-gsm-device.c I get to connect successfully. For what reason was that append in there? And why does it work for everybody else? I'm clueless. Your phone number in the applet is set incorrectly. It should be *99#, not *99***1. Use the connection editor to change it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: UMTS Vs. GSM Vs. GPRS
On Thu, Jul 24, 2008 at 4:15 PM, André Lemos [EMAIL PROTECTED] wrote: I am a bit confused by the options regarding mobile broadband. Under Advanced - Type, I have GSM and GPRS. What about UMTS (3G)? Is it one of them supposed to be 3G? Where's that Advanced - Type? NetworkManager (and nm-applet) have two types for mobile broadband devices: GSM (includes GPRS, EDGE, UMTS, HDSPA, ...) and CDMA. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: UMTS Vs. GSM Vs. GPRS
On Thu, Jul 24, 2008 at 6:23 PM, André Lemos [EMAIL PROTECTED] wrote: Please see the attached screenshot. That's for Type. Band is just empty. Oh right, sorry. I didn't even remember we had that there because it's not used currently (same for band). The known values for cards seem to be: prefer GPRS, prefer UMTS (3g), GPRS only, UMTS (3g) only So I guess it should be 'UMTS' in the applet. For now, whatever the card defaults to is used. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [REQUEST] Mobile Broadband
On Thu, Jul 24, 2008 at 5:45 PM, André Lemos [EMAIL PROTECTED] wrote: Is there any technical reason why the signal strength isn't implemented for Mobile Broadband? Yes. The command is: at+csq +CSQ: 12,99 It would be especially useful for when connected, and different cards have different ways to do it. Some devices have two serial devices (although the output format differs), some have a proprietary (non AT command based) binary interface for it, some have just one device and have some sort of multiplexing. The current modem handling code is very basic and it doesn't handle non standard (defacto) operations. I'm working on it right now and should have something to share very soon. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Enable dhcpcd instead of dhclient
On Thu, Jul 17, 2008 at 11:24 AM, Roy Marples [EMAIL PROTECTED] wrote: The current configure environment forced me to install ppp for the development headers. I neither use nor care about ppp, so the same argument could be applied there. Not really. ppp is a build time dependency, NM would not build without it. dhcp clients are runtime dependencies. Tambet The reason why it's a build time check is that it's a lot easier to check the clients work in a shell script than in C at runtime. 1) Only dhcpcd-4 works with NM - older versions will not 2) Only ISC dhclient works with NM - derived versions will not (OpenBSD and FreeBSD have their own trimmed down versions with POSIX command line and don't have all the options needed) I'd say, if an absolute path is given (i.e. --with-dhcp-client=/sbin/dhclient), simply take this path and do no further checks. Imo it's safe to assume, if someone is using the configure flag this way, he knows what he's doing. That's probably a safe assumption to make. Thanks Roy ___ 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: disabling polkit?
On Thu, Jul 17, 2008 at 11:58 AM, Steve [EMAIL PROTECTED] wrote: Hello! How integrated is polkit in NetworkManager? I would like to build NM for Slackware, which doesn't come with polkit, and I would like to try avoid installing it if I could. I'm just if it would be possible (without major changes to code) to build nm without it? At the moment I'm using an older version of NM from svn that doesn't require polkit. There's one place in NetworkManager (system-settings/src/nm-polkit-helpers.c) and one place in NetworkManager-gnome (src/connection-editor/nm-connection-list.c) where you can patch it out. But that would mean any user would be able to change system network configuration and it's probably not a good idea. It would probably be a better bet to convince slackware to include policy kit as more and more programs are starting to use it. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: System Setting - Wireless - WPA - and Fedora 9
On Tue, Jul 15, 2008 at 8:43 PM, Dan Williams [EMAIL PROTECTED] wrote: Hmm, could be that the encryption key didnt work the first time. We really should implement get_secrets() for keyfile though. That's the problem here. Why? Why would it succeed later if it failed initially? When the keyfile configuration changes, it's re-read automatically, including all the secrets. If reading WPA-EAP secrets does not work, that needs to be fixed, just providing another function that will fail the same way won't fix anything. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Simple connect feature for xl2tpd
On Tue, Jul 15, 2008 at 7:27 PM, David Smith [EMAIL PROTECTED] wrote: Dan, how set are you on using NSS? I believe this job is better fit for just supporting PKCS#11 in NM and making nm-applet use gnome-keyring's PKCS#11 interface by default. Using just PKCS#11 is a much lighter dependency and far simpler design. Also, using NSS in NM would require it to be integrated in the supplicant, but wpasupplicant already supports PKCS#11. I'm very excited about these patches and I definitely would like to see it finished (the applet part). Much better to have it now rather than ideas how to do it differently later. Plus, NSS backend for gnome-keyring is in their todo list. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Enable dhcpcd instead of dhclient
On Tue, Jul 15, 2008 at 5:34 PM, Roy Marples [EMAIL PROTECTED] wrote: On Tue, 15 Jul 2008 15:29:43 +0100, Roy Marples [EMAIL PROTECTED] wrote: Please apply this to NetworkManager :) LOL - here is the patch :) The patch looks good to me, just a small nitpick, the configure script should work without needing to always provide --with-dhcp-client flag and default to dhclient. Also, please forgive my ignorance, are the environment variables in the dhcpcd script identical to the ones in dhclient? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] po fixes
On Thu, Jul 10, 2008 at 3:22 PM, Michael Biebl [EMAIL PROTECTED] wrote: the changes in r3817 were unfortunately incorrect and cause make distcheck to fail. Instead of adding vpn-daemons/openvpn/properties/auth-helpers.c to po/POTFILES.in, it has to be added to po/POTFILES.skip. I also cleaned up the latter file from 2 files, which either no longer exist or don't have any translations. This was fixed with r3818, right? Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: small fixes for de.po
On Fri, Jul 11, 2008 at 12:20 PM, Markus Becker [EMAIL PROTECTED] wrote: attached are some small de translation fixes. Thanks, r3820. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Determining what NetworkManager is getting from UserSettings
On Sun, Jun 15, 2008 at 9:12 PM, Christopher Blauvelt [EMAIL PROTECTED] wrote: Is there a way (log files, debug flags that can be set at runtime) that I can determine what information NetworkManager is getting from my UserSettings daemon? No, but you can add nm_connection_dump (connection) to src/nm-manager.c:connection_get_settings_cb(). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Examples for org.freedesktop.NetworkManagerSettings.Connection.Secrets
On Sun, Jun 8, 2008 at 7:50 PM, Christopher Blauvelt
[EMAIL PROTECTED] wrote:
I'm trying to make an NM Settings daemon and I'm having trouble finding what
parameters are passed to GetSecrets and what NM expects in return.
What kind of values are passed as setting_name? Is it the connection name
'nifty-wireless' or is it something like '802-11-security'?
The setting name for which the secrets are needed. Something like
802-11-wireless-security, 802-1x, gsm, ... The connection name
(like 'nifty-wireless') is not needed since GetSecrets is already a
method of a(n existing) connection.
Is hints something along the line of {'key-mgmt', 'wep-tx-keyidx',
'wep-key0'}?
Yes.
Tambet
I appreciate any help. In addition I'd be willing to help document the
project if you would like the help. So I'll probably be asking several
questions in the future. I've been on IRC (Freenode #nm) all weekend but
have yet to see a core dev on there. Do y'all hang out during the
weekdays? If so what timezone do you live in so I can try and be on when
you are.
Thanks,
Chris
___
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: tell networkmanager which wireless card to use?
On Wed, Jun 4, 2008 at 11:16 AM, Xamindar [EMAIL PROTECTED] wrote: I haven't looked into it that much. But I was wondering what happens if you have two wireless cards in the pc..which one does it use? More importantly, is there a way to tell it NOT to use a certain card at all? On redhat and suse, you can add NM_CONTROLLED=no line to /etc/sysconfig/network/ifcfg-$interface file. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Adding a signal for a connection removed
On Tue, Jun 3, 2008 at 5:58 AM, Christopher Blauvelt [EMAIL PROTECTED] wrote: What do you all think of having a signal on the service org.freedesktop.NetworkManagerSettings when a connection is removed instead of just added. If the keeping the current naming convention is desired, the new signal could be called RemovedConnection. If not, then ConnectionAdded and ConnectionRemoved sound more natural. This functionality is already present in NM. The signal 'org.freedesktop.NetworkManagerSettings.NewConnection' is emitted when a connection is created with an argument of the exported connection's object path. Any changes to that connection are notified with the signal 'org.freedesktop.NetworkManagerSettings.Connection.Updated' and when the connection is removed, signal 'org.freedesktop.NetworkManagerSettings.Connection.Removed' is used. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: API break / so versioning
On Fri, May 30, 2008 at 9:31 PM, Dan Williams [EMAIL PROTECTED] wrote: On Fri, 2008-05-30 at 20:13 +0200, Michael Biebl wrote: What you can easily notice (by running a diff), ist that not only a lot of symbols were added, but also quite a few were removed, which could result in application crashes. In case of an API break, you usually bump the SOVERSION, which leads to the more general question, if NM shouldn't start using proper soversioning [1]. Yes, it probably should. One thing that we've tried to do is keep the old libnm_glib symbols around though, which is why we kept the libnm_glib name instead or renaming it to libnm-glib instead. So that at least apps that used the old basic 0.6 API bits would still work. There's probably no point in keeping that anymore. The basic API is kept, but some of the basic defined variables have changed (NMDeviceState), so even if something might still compile, it probably doesn't work anymore. If we're willing to ditch that assumption, then I'm all for removing that code and bumping the soname. I also wondered, if the separate library libnm_glib_vpn.so.0 is really necessary or should be folded into libnm_glib.so.0. This is used by the VPN services and isn't really part of the same bits that should be used by clients of NM. I tend to think we should keep them separate, since if you're writing a client like nm-applet you shouldn't care about anything that's in libnm_glib_vpn. Maybe Tambet has more thoughts? Yes, these should be separate. One (libnm-glib) is part of the client, the other (libnm-glib-vpn) part of the daemon. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Delay full modem initialization until SIM is unlocked
On Thu, May 29, 2008 at 2:12 PM, Dennis Noordsij [EMAIL PROTECTED] wrote: I'd like to further improve easy of use with gsm devices, but it would help if someone could point me in the right direction (i.e. what needs to be touched to implement this, does it need HAL support, does it belong in NM, or nm-applet specific?) or comment on the following: The general design should be to add new methods/properties to NMGsmDevice class and expose these over dbus in the introspection/nm-device-gsm.xml. - The device supports being on and off. I.e., at startup it could be allowed to just connect to a network. Then, setting up a data connection will be very fast since it doesn't have to find the network first. The nm-applet would allow you to disable the modem the same way you disable wireless; the modem can be told to turn off its radio and save power that way, and similarly will join a network again once the radio is turned back on. I think this applies to all gsm modems (AT+CFUN command), so perhaps does not need special HAL attributes. Good idea. It is marked as an optional feature in the specification, so it might or might not work. I guess it could just be a noop if the device doesn't support it. It should probably be a propery of NMManager class (just like turning wireless on/off) which in turn iterates over all registered devices and calls their enable/disable radio method. - The init can be improved a bit, i.e. making sure the settings are sane and the radio is actually on (otherwise NM will loop forever waiting for a network to be joined). Yeah, totally. - It would be nice if the nm-applet could display which network is being used (once a data connection has been made) and wether it's the home network or roaming. - Similarly, it would be nice to know which data mode is being used. For these two we'd need to support monitoring. See my comments to the next block. - This device (Dell branded Novatell EU780D) has a second port which can be used for status queries. It uses a binary protocol which turns out to be AT commands over a variation of the Brew protocol (bitpim was helpful to find the crc algorithm etc), Actually the Windows driver does everything except the actual dialing and PPP over the second port. It means with this device you are able to monitor the signal strength and battery status (in case you're using a mobile phone as a modem over usb or bluetooth) even while you have a data connection up. This would need changes I guess in a lot of places, HAL to identify and tag this modem as having this capability; a small lib to do the AT request/response encoding, etc, but it would be really nice to have. This is actually needed for a lot of functionality, but it looks like the monitoring device is not standardized and (almost?) every device has it's own way of doing things. Some have proprietary binary formats, some have AT commands. If it's done in NM, I'd like to implement a plugin system for this, otherwise the code will get unreadable and unmaintainable very quickly... Another possibility we've been considering is to delegate all the dialup handling to an out of process helper program, much like wpa_supplicant is used for wireless. The lack of standards and lack of implementing existing standards in mobile devices makes it a very difficult job to support a wide range of hardware and it probably deserves a dedicated program. The requirements from NM are that the program implements easy to use high level dbus interfaces that abstract all the quirks (again, much like wpa_supplicant). Currently, the only candidate for this is VMC, Pablo could give more information on that. - Not GSM specific, but relevant since data traffic is usually not flat-fee, to have sent/received byte counters. (i.e. is this something NM would broadcast over dbus or would nm-applet just query the device itself?) Very good suggestion again, I'll look into doing it right away. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Delay full modem initialization until SIM is unlocked
On Sat, May 24, 2008 at 11:02 PM, Dennis Noordsij [EMAIL PROTECTED] wrote: Some modems return ERROR to most AT commands when the SIM is still locked, specifically the ATZ E0 in the initialization. The attached patch modifies the initialization sequence to disable the local echo (the E0 part) first, perform the SIM check, and only then continue with the ATZ and further network registration, etc. For me, on fresh boot (SIM locked), this NetworkManager now unlocks the SIM (it has my PIN in the keyring) and makes a perfect connection every time. The patch looks good to me, thanks! PS I imagine this might apply to CDMA as well. Does CDMA even have PIN codes? At least our code doesn't think it does. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Suitability for embedded linux device
On Wed, May 28, 2008 at 12:01 PM, Nitin Mahajan [EMAIL PROTECTED] wrote: I was going through the features of Network Manager. The D-BUS API feature is very interesting. Whether the Network Manager is suitable to be used in Embedded Linux device, without GNOME? It should be, yes. The only additional dependecies on top of what DBus and HAL already have are libnl, dbus-glib, policy-kit, a crypto library (mozilla-nss or gnutls) and wpa_supplicant. So additional dependencies to any other implementation should be only dbus-glib and policy-kit, neither of those should be unsuitable for embedded devices. NM shouldn't use a lot of resources (memory or CPU) either. I also wanted to know, Whether the Network Manager has any distribution specific dependencies? If yes how tightly they are coupled with the distribution? All (currently, almost all, but that's going to change) the distribtion specific code is moved out of NetworkManager and into the system settings daemon. That daemon is modular used to provide configurations (connection informations) to NM. Currently there are 3 backends for it: Fedora and SUSE (to parse /etc/sysconfig/network/*) files and also a generic GKeyFile (.ini -like) native backend which works on any distribution. So, for example, there's no debian backend for it, but that does not mean it does not work on debian (in truth, it sort of doesn't, but that's because of dbus configuration differences, not directly caused by NM code). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Suitability for embedded linux device
On Wed, May 28, 2008 at 12:46 PM, Nitin Mahajan [EMAIL PROTECTED] wrote: Thanks for your inputs. libcrytpo from openssl will not work? Currently, no. But it would be pretty easy to add since it would need to implement only 3 functions to handle certificate and private key loading and verifying. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Connecting to hotel wireless networks
On Thu, May 22, 2008 at 5:21 PM, Michael Duvall [EMAIL PROTECTED] wrote: On a recent business trip I was unable to connect to two different hotel wireless networks, yet I had no problem with getting an IP from a McDonalds restaurant or at the Fort Worth airport. As for the hotels, my co-worker that has a Windows laptop had no problem with either hotel. I tried to troubleshoot the problem, but had no success. My guess is that the hotel wireless networks were poorly configured, however if a Windows laptop connected I think that there must be a way to get a Linux laptop to work. Of course, when one tries to get tech support at hotels, the customer service reps eyes glass over when they find out that I'm running Linux Go figure. I am running 2.6.24.7-92.fc8 with the latest updates as of May 16, 2008. Below is the captured output from the NetworkManager. Any and all suggestions/recommendations will be greatly appreciated. For this specific log I can not suggest anything, it looks like the DHCP server just never replied. But I just committed a little workaround for poorly configured networks often found in hotels and airports: The default gateway returned by DHCP server is not in the same subnet as the assigned IP, so adding the default route fails. The workaround for it is to first add a direct route to the gateway machine and then the default route. Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
