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: Lockdown nm-applet once again
On Wed, Jan 20, 2010 at 02:07, Dan Williams 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: Are there any command-line front-ends for network-manager?
On Wed, Jan 20, 2010 at 02:53, Dan Williams 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: Questions about ModemManager
On Fri, Sep 25, 2009 at 12:50, Ozan Çağlayan 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): <-- '+CME ERROR: > 11' > ** (modem-manager:7311): DEBUG: Got failure code 11: SIM PIN required > ** (modem-manager:7311): DEBUG: (ttyUSB0): --> 'AT+CFUN=1' > ** (modem-manager:7311): DEBUG: (ttyUSB0): <-- 'OK' > ** (modem-manager:7311): DEBUG: (ttyUSB0): --> 'AT+CSQ' > ** (modem-manager:7311): DEBUG: (ttyUSB0): <-- '+CME ERROR: > 11' > ** (modem-manager:7311): DEBUG: Got failure code 11: SIM PIN required > ** (modem-manager:7311): DEBUG: (ttyUSB0): --> 'AT+CPIN=""' > ** (modem-manager:7311): DEBUG: (ttyUSB0): <-- 'OK' > ** (modem-manager:7311): DEBUG: (ttyUSB0): --> 'AT+CSQ' > ** (modem-manager:7311): DEBUG: (ttyUSB0): <-- '+CSQ: > 13,99OK' > ** (modem-manager:7311): DEBUG: (ttyUSB0): --> 'ATDT*99#' > ** (modem-manager:7311): DEBUG: (ttyUSB0): <-- 'NO CARRIER' > ** (modem-manager:7311): DEBUG: Got failure code 3: No carrier > ** (modem-manager:7311): DEBUG: (ttyUSB0): --> 'AT+CEER' > ** (modem-manager:7311): DEBUG: (ttyUSB0): <-- '+CEER: No cause > information availableOK' +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 wrote: > On Thu, Sep 17, 2009 at 2:11 PM, Tambet Ingo wrote: >> On Thu, Sep 17, 2009 at 06:16, Bin Li 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 12:14, Bin Li wrote: > On Thu, Sep 17, 2009 at 2:11 PM, Tambet Ingo wrote: >> >> On Thu, Sep 17, 2009 at 06:16, Bin Li 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
Re: Question about function applet_get_best_activating_connection()
On Wed, Sep 16, 2009 at 05:54, 代尔欣 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 06:16, Bin Li 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
[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
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
+
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 @@
+
+
+ The NetworkManager version.
+
+
+
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
#include
#include
@@ -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/nm-manager.h b/src/nm-manager.h
index 0c6da15..6bf1324 100644
--- a/src/nm-manager.h
+++ b/src/nm-manager.h
@@ -39,6 +39,7 @@
#define NM_MANAGER_WIRELESS_ENABLED "wireless-enabled"
#define NM_MANAGER_WIRELESS_HARDWARE_ENABLED "wireless-hardware-enabled"
#define NM_MANAGER_ACTIVE_
Re: Bug report for connecting to eap-tls wireless network with a CA chain
On Wed, Sep 9, 2009 at 05:05, zign 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 Wed, Sep 2, 2009 at 15:39, Alexander Sack 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: network-manager-netbook with NetworkManager 0.8
On Tue, Sep 1, 2009 at 02:47, Peter Robinson 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: APN list: adding mcc & mnc
On Wed, Apr 22, 2009 at 11:17, Martijn Cox (LiveContacts) wrote: > Sorry for the delayed response, I have been busy otherwise. Attached, you'll > find our complete list of mnc&mcc 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: Elisa ... or, if people hate attributes (as it appears from the current schema :), just tags inside "provider": 248 02M Elisa ... or, just one attribute/tag for mcc/mnc code, it's not rocket science to split it in code (if needed): ... 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 12:59, Hooker, Jonathan 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: Issue with Auto eth0
On Fri, Apr 3, 2009 at 10:51, Hooker, Jonathan 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
2009/4/3 Hooker, Jonathan : > Hi, > > I am a system administrator for a large (300+) fedora desktop environment > and am in the process of creating a new image to deploy to all of my > developers. I have been having issues with setting up NM to connect properly > to our dhcp servers so that we can configure forward dns lookups. Basically > what I have done is create an Auto Ethernet connection which has the > following gconf settings: > > /system/networking/connections/1/ipv4: > routes = [] > addresses = [] > method = auto > dhcp-hostname = testd63fed > dhcp-client-id = nixdns-testd63fed > dns-search = [garmin.com,ad.garmin.com,nix.garmin.com] > name = ipv4 > dns = [] > /system/networking/connections/1/802-3-ethernet: > name = 802-3-ethernet > duplex = full > /system/networking/connections/1/connection: > id = Auto Ethernet > timestamp = 1238728735 > type = 802-3-ethernet > uuid = 2d204a05-4c70-4080-ad23-34b53d5a95fe > name = connection > The problem is that this does not by default start when the system does. I > have also tried putting these settings in the root user's gconf. Is there > any way I can tell Network Manager to by default select Auto Ethernet as > opposed to the standard System eth0? I know that System eth0 pulls from my > ifcfg-eth0 scripts but there is no way I can tell of sending the > dhcp-hostname and dhcp-client-id back to the dhcp server without using this > or dhclient. I would really like for all of my network device settings to be > managed from the same program. Any suggestions would be greatly appreciated! NetworkManager has two types of setting providers: User settings (from gconf, available only while the user is logged in) and System settings (always available). System settings have different sources (plugins) that allow taking configuration data from multiple sources (distro specific shell script setups, NM's own store, ...). The problem with supporting these different sources is that they never match one to one with NM - Missing variables, extra variables, variables with slightly different meanings, ... So you'll want a "System setting" with NM's own store. Here's how you can do it: * Modify /etc/NetworkManager/nm-system-settings.conf file's [main] section, 'plugins' keyword so it only has "keyfile" (NM's native settings storage): plugins=keyfile That'll make sure you have a writable plugin and the distro one (which doesn't provide all the options you require) doesn't interfere. Put that changed configuration to your deployment image. * Restart nm-system-settings by issuing 'sudo killall nm-system-settings'. NetworkManager will restart it automatically. This step is needed to make the system settings provider use the new configuration from step 1. * As any logged in user, open the connection editor (nm-applet's right-click menu, Edit Connections...), create the configuration you'd like to use, and check "Available to all users". The last step is important, that's the switch between User connections and System connections. You want system connection, aka available to all users. This last step will create a configuration file in /etc/NetworkManager/system-connections/ directory that contains all the connection information. Put that to your deployment image. With these settings, NetworkManager will activate the connection on system boot, before any user is logged in, using all the settings known to NM. 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 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 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: [RFC] Make scan mode configurable
On Tue, Feb 10, 2009 at 14:20, Daniel Wagner 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
Re: [RFC] Make scan mode configurable
On Tue, Feb 10, 2009 at 12:45, Daniel Wagner 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: dbus and OpenVPN Autostart
On Mon, Feb 9, 2009 at 18:47, Dan Williams 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_conne
Re: NetworkManager integrated with ModemManager
On Mon, Feb 9, 2009 at 15:14, Darren Albers 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
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
ModemManager-0.2 released.
Hello, I'm happy to announce the first official release of ModemManager: http://people.freedesktop.org/~tambet/ModemManager-0.2.tar.gz The most important recent changes: * Moved to git.freedesktop.org. The old tree at gitorious.org is not used anymore. Clone the new tree from git://anongit.freedesktop.org/ModemManager/ModemManager . * Change the DBus return values that returned multiple values. It turned out DBus python bindings did not support that and to make it possible to implement ModemManager interfaces in python, these methods now return tuples. * Changes to the 'org.freedesktop.ModemManager.Modem.Gsm.SMS' interface as suggested by Pablo Martí Gamboa (http://mail.gnome.org/archives/networkmanager-list/2009-January/msg00194.html). * Implement 'org.freedesktop.ModemManager.Modem.Simple' interface. It's a very simple wrapper with just two methods on top of existing functionality to make it as easy as possible to get a modem connected and to query it's status. * Define generic IP address receiving methods to avoid modem specific implementations in applications that use ModemManager. In order to do so, 'org.freedesktop.ModemManager.Modem' interface was extended with: - 'IpMethod' property. It's an 'uint' type with 3 possible values: 0 - ppp (use PPP to get the IP address, most modems), 1 - static (ask IP address from modem, used with HSO modems), 2 - DHCP (run dhcp on the provided device, used with MBM modems). - 'GetIP4Config' method. It's implemented only in case 'IpMethod' property returns 1 (static) and returns a tuple containing (address, dns1, dns2, dns3). - 'DataDevice' property is renamed to 'Device'. It's always the IP device for the modem. 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 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 > > > > Yes, they do have broken 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: DBus permissions
On Tue, Jan 27, 2009 at 15:26, Martin Vidner wrote: > What about introspection? If it is not allowed globally then we need > also this: > > > > send_interface="org.freedesktop.DBus.Introspectable"/> > My patches take care of introspection and DBus properties by not limiting destinations to different interfaces (where it makes sense). 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 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
DBus permissions
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 Tambet diff --git a/callouts/nm-avahi-autoipd.conf b/callouts/nm-avahi-autoipd.conf index 97d9ff5..52e8ea0 100644 --- a/callouts/nm-avahi-autoipd.conf +++ b/callouts/nm-avahi-autoipd.conf @@ -2,13 +2,9 @@ "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> - - - - - - - - + + + + diff --git a/callouts/nm-dhcp-client.conf b/callouts/nm-dhcp-client.conf index 515a110..cc7723a 100644 --- a/callouts/nm-dhcp-client.conf +++ b/callouts/nm-dhcp-client.conf @@ -2,13 +2,9 @@ "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> - - - - - - - - + + + + diff --git a/callouts/nm-dispatcher.conf b/callouts/nm-dispatcher.conf index 32833a7..8dbc0b5 100644 --- a/callouts/nm-dispatcher.conf +++ b/callouts/nm-dispatcher.conf @@ -4,11 +4,7 @@ - - - - - + diff --git a/src/NetworkManager.conf b/src/NetworkManager.conf index 01dfee2..5378e5d 100644 --- a/src/NetworkManager.conf +++ b/src/NetworkManager.conf @@ -2,29 +2,16 @@ "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> - - - - - + + + + + - - - - - - - - - - - - - - - - + + send_interface="org.freedesktop.NetworkManager.PPP"/> + -512 + 512 diff --git a/system-settings/src/nm-system-settings.conf b/system-settings/src/nm-system-settings.conf index 10184ba..6e95f3a 100644 --- a/system-settings/src/nm-system-settings.conf +++ b/system-settings/src/nm-system-settings.conf @@ -2,23 +2,17 @@ "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> - - - - - - - - - - - - - + + + + + -512 + 512 diff --git a/nm-applet.conf b/nm-applet.conf index af7c642..2081ab0 100644 --- a/nm-applet.conf +++ b/nm-applet.conf @@ -2,31 +2,18 @@ "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd";> - - - + - - - - + - - - - - - - - - - - - - + + + 512 diff --git a/nm-vpnc-service.conf b/nm-vpnc-service.conf index cd02870..4cee63e 100644 --- a/nm-vpnc-service.conf +++ b/nm-vpnc-service.conf @@ -5,12 +5,6 @@ - - - - - - diff --git a/nm-openvpn-service.conf b/nm-openvpn-service.conf index 62eaa8c..c6b5eb2 100644 --- a/nm-openvpn-service.conf +++ b/nm-openvpn-service.conf @@ -5,12 +5,6 @@ - - - - - - diff --git a/nm-pptp-service.conf b/nm-pptp-service.conf index aa5400d..b1b80d2 100644 --- a/nm-pptp-service.conf +++ b/nm-pptp-service.conf @@ -4,21 +4,9 @@ - - - + - - - - - - - - - - diff --git a/nm-openconnect-service.conf b/nm-openconnect-service.conf index 2cc1c27..3d4841f 100644 --- a/nm-openconnect-service.conf +++ b/nm-openconnect-service.conf @@ -5,17 +5,10 @@ - - - - - - - ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Some SMS API suggestions for ModemManager
On Tue, Jan 20, 2009 at 18:08, Pablo Martí Gamboa wrote:
> I've got a couple of suggestions for the MM API regarding SMS:
>
> - org.freedesktop.ModemManager.Modem.Gsm.Sms.Send/Save:
>* Change in_signature from 'ss', to 'a{sv}': The current API, albeit
> simple, is not powerful enough for some scenarios. You cannot specify SMSC,
> validity, message class, etc. It would keep two mandatory keys: 'number',
> 'text', and the following three would be optional: 'smsc', 'validity' and
> 'class'. This of course can be extended in the future.
> * Change out_signature from 'u' to 'au': The current API assumes that is
> dealing with single part messages, but when you send/save a multipart one,
> you get n indexes if the SMS has been splitted into n parts.
> - org.freedesktop.ModemManager.Modem.Gsm.Sms.List:
>* Change out_signature from 'a(ussd)' to 'aa{sv}': The current signature
> suffers from the same problems than the in_signature in Sms.Send/Save.
> There's no way to obtain the smsc, validity, class, etc. Furthermore, a
> stored SMS in the SIM does not have a timestamp encoded in the pdu, so the
> 'd' from 'a(ussd)' wouldn't be necessary. One last thing is that the SIM
> orders messages into four categories:
> - 0: Unread messages
> - 1: Read messages
> - 2: Unsent stored messages
> - 3: Sent stored messages
>
>Supporting this is mandatory for any application that pretends to provide
> a decent SMS experience. This field is commonly referred as 'stat'.
>This dictionary then would have the following mandatory keys:
>
> * 'index' (u)
> * 'number' (s)
> * 'text' (s)
> * 'stat' (u)
>
>And the following keys would be optional:
> * 'class' (u)
> * 'validity' (d)
> * 'timestamp' (d)
>
> Accordingly, the out_signature of Sms.Get should be changed to 'a{sv}'.
>
>
> Any thoughts?
Sure, I have no problems with that change. Unless anyone objects, I'll
commit this change in a couple of days.
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 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 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 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 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: Multi Active Devices
On Sat, Dec 20, 2008 at 16:32, Etienne Zind wrote: > I'm using the NetworkManager shipped in the last Ubuntu distro (0.7). I've > been > able to connect few devices in the same time as expected (eth0, ppp0, wan0). > As > expected too, although all three ISPs are connected only one (eth0) is > actually > used (default route). The way NM updates the route table prevents any packet > to > be routed by another device than the default one even if specified on > software: > > $ wget --bind-address=$IP_WAN0 http://foo.bar/index.html # fails > $ wget --bind-address=$IP_PPP0 http://foo.bar/index.html # fails > $ wget --bind-address=$IP_ETH0 http://foo.bar/index.html # OK > > So I had a look at the "Linux Advanced Routing & Traffic Control HOWTO" by > Bert Hubert [1] and implemeted the setup [2] described in the "Routing for > multiple uplinks/providers" and it did work perfectly (even with a trivial > load > balancing over the 3 ISPs with the multipath default route). I seriously doubt people want load balancing in general (for example, in case of active ethernet and modem devices). There are many possibilities for setting up routing in case of multiple active devices (like split access, load balancing, failsafe/backup, ...) and we have no way of configuring that with NM right now. We have data structures for connections (one per active device), but we don't have defined relations between them. > The basic idea is to use many routing tables together, and some rules to > define > which table to use. I implemented it in a perl script that I execute manualy > everytime something change in the NM environement (how to do that > automaticaly ?) Whenever a device is activated/deactivated, the dispatcher scripts are called from /etc/NetworkManager/dispatcher.d/ directory, so you should put your script there and test how your script is called. The first argument passed to the scripts is the device interface name, the second is "up" or "down". > I would love to get my fingers dirty in your elegantr GObj C code, although I > might need some "emlightment" from you guys to be sure it worth it. > Please have a look at my shell script (working). Any comment will be > welcome. I couldn't see it, it kept timing out for me, but it would be a good start to convert it to C and use libnl so that it would be easy to add to NM when it's ready. Tambet > > [1] http://lartc.org/howto/index.html > [2] http://parad0x.org/~barbu/dev/mad/mad-setup.pl > > -- > Regards, > Etienne Zind > > ___ > 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: DBus Properties 0.7.0 Device question
On Thu, Dec 18, 2008 at 11:34, Simon Schampijer wrote: > Tambet Ingo wrote: >> >> On Wed, Dec 17, 2008 at 22:39, Simon Schampijer >> 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: DBus Properties 0.7.0 Device question
On Wed, Dec 17, 2008 at 22:39, Simon Schampijer 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 ___ 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 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: NetworkManager core daemon moved to git
On Tue, Dec 16, 2008 at 17:35, Dan Williams wrote: > They may bitrot, but they aren't for anything critical, and should not > be used for UI strings anyway. Most of them are for GError translations > from libnm-util crypto stuff. Some may be for system settings plugins. > We'll have to do a bit more work to get them translated, yes, but I > don't believe that it's critical. Should system daemons (NM and nm-system-settings) be translated at all? Isn't the C locale used for these anyway? Actual users can have any locale which (usually?) is different. GErrors have error codes which UIs can use to show user visible errors. 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 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: Error compiling network-manager-applet
On Tue, Nov 18, 2008 at 1:06 PM, Santiago Capel Torres <[EMAIL PROTECTED]> wrote: > I've got both programs from the current SVN repositories, shouldn't they be > in sync? They are, but you also tell nm-applet where to look for the headers and libraries and it looks like it finds the wrong ones (by distro's packages most likely). When you run configure for NetworkManager, pass --prefix=/foo/bar and before configure in nm-applet, set 'export PKG_CONFIG_PATH=/foo/bar/lib/pkgconfig:$PKG_CONFIG_PATH' environment variable. 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 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 > < > >Fuji Network Ex,Koi Modem,Koi Network,Scorpion Modem,Scorpion > Network,Etna Modem,Etna Network,Etna Modem Lite;Etna Modem Gt, > 36c36 > < 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"> > --- >> 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 > < > < > < > < type="strlist">GSM-07.07 > < type="strlist">GSM-07.05 > < > < > < > 184c176 > < > --- >> > 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 > < int_outof="0x8114;0x8117;0x8128;0x8129;0x8133"> > --- >> int_outof="0x8114;0x8117;0x8128;0x8129;0x8133;0x8134"> > 354,355c346,347 > < > < int_outof="0x4f9;0x64;0x2f;0xab;0x418;0x4f0;0x4ce;0x43a;0x44d;0x070;0x3a;0x72"> > --- >> >> int_outof="0x4f9;0x64;0x2f;0xab;0x418;0x4f0;0x4ce;0x43a;0x44d;0x42;0x72;0x70;0x3a"> > 369c361 > < > --- >> > > > 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: 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: 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: 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: 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: 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: 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: Can nm provide connection speed ?
On Mon, Nov 3, 2008 at 11:22 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote: > This way we could make both Totem and PackageKit happy (the former > needs bandwidth to optimize streaming, the latter doesn't want to pull > updates on GPRS and needs bandwidth to throttle the background > downloads). The active device type is already available on the NetworkManager DBus API. The broadband modem speed (at least network type, ie gprs/3g/...) will be available in the near future. But having every application know so much about different device types and their details, not to mention that active 1gig ethernet device usually doesn't mean you have that connection speed, I think there is room for some sort of library or service that is implemented on top of NM but below user applications. 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: [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: [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: [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 Fri, Oct 24, 2008 at 7:13 AM, Bin Li <[EMAIL PROTECTED]> wrote: > Generally the openvpn configuration file set the ca, cert and key file > without the absolute path, and > the openvpn could find these file in the same path of the > configuration file. Just run this: > > # openvpn --config Client-config.ovpn > > openvpn works fine. Client-config.ovpn, ca.crt client.crt and > client.key in the same directory. > > And when I import the openvpn configuration file, the > nm-connection-editor couldn't set the ca, cert and key file. > > This patch will works for it. It leaks 'default_path' variable in do_import(). I'd also use g_build_filename() in handle_path_item() in case the path isn't absolute. 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 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 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 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: Activation (ttyACM0) starting connection 'Vodacom' > NetworkManager: (ttyACM0): device state change: 3 -> 4 > NetworkManager: Activation (ttyACM0) Stage 1 of 5 (Device Prepare) > scheduled... > NetworkManager: Activation (ttyACM0) Stage 1 of 5 (Device Prepare) > started... > NetworkManager: [1224572376.061516] nm_serial_device_open(): > (ttyACM0) opening device... > NetworkManager: Activation (ttyACM0) Stage 1 of 5 (Device Prepare) > complete. > NetworkManager: [1224572376.169089] nm_serial_debug(): Sending: 'ATZ > E0 V1 X4 &C1 +FCLASS=0 > ' > NetworkManager: [1224572376.196931] nm_serial_debug(): Got: 'ATZ E0 > V1 X4 &C1 +FCLASS=0 > ' > NetworkManager: [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 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: 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: 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: 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: 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: 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: 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 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: 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: 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 **: 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 **: [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: 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: [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: [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)
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 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 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 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: [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)
Hey,
First of all, thanks for your comments!
On Wed, Aug 27, 2008 at 1:54 PM, Pablo Martí <[EMAIL PROTECTED]> wrote:
> The Wader project has started to port its API to the one defined by
> ModemManager. While doing so we've got some input for the API design.
> The interfaces currently defined are too "flat":
> This interfaces might be enough for ModemManager's purposes as MM is
> just interested on 5/6 commands, but for projects like Wader where we
> export 40+ methods this flat namespace is nothing but ideal. The
> exported methods could be grouped into five different areas:
>
> o.f.MM.M.G.Card
> o.f.MM.M.G.Contacts
> o.f.MM.M.G.Network
> o.f.MM.M.G.PIN
> o.f.MM.M.G.SMS
Yeah, agreed.
I reordered the interfaces a bit:
> org.freedesktop.ModemManager.Modem.Gsm.Card: SIM/Card related operations
> - DisableEcho() ->
> - EnableEcho() ->
These do not do anything useful from the API user's perspective and
shouldn't be included in the public API.
> - Enable(b enable) -> (This is the Enable method of ModemManager, I
> think it goes here but I might be completely wrong here :)
Yes. Enable() means initialize the card and check if any secrets are
needed (PIN/PUK).
> - GetCharset -> s
> - GetCharsets() -> as
> - SetCharset(s charset) ->
Do we need these? Do the modems support UTF8? If they do, let's just
default to that. The reason I don't like there much is that they seem
a bit too low level.
> - GetIMEI() -> s
> - GetIMSI() -> s
> - GetManufacturer() -> s
> - GetModel() -> s
> - GetVersion() -> s (Firmware version)
All good ones.
> - ResetSettings() -> (ATZ)
That's what Enable(True) does (among other things).
> 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.
> 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?
For the following methods I don't have strong preferences because I've
never used any of these features and thus don't have any hands on
experience. I'd really appreciate if other interested parties
(Telefonica?) could comment these.
> org.freedesktop.ModemManager.Modem.Gsm.Contacts: Contact related operations:
> - Add(s name, s number) -> u
> - Delete(u index) ->
> - Find(s pattern) -> a(uss)
> - Get(u index) -> (uss)
> - GetPhonebookSize() -> u(Could be renamed to GetSize() ?)
> - List() -> a(uss)
Looks good to me.
> org.freedesktop.ModemManager.Modem.Gsm.SMS: SMS related operations:
> - Delete(u index) ->
> - Get(u index) -> (ussd)(The last double is the time when it
> was received)
> - GetFormat() -> u (AT+CPBF?)
> - GetSMSC() -> s
> - List() -> a(ussd)
> - Save(s text, s number) -> u
> - Send -> u
> - SendFromStorage(u index)
> - SetFormat(u format) ->
> - SetIndication(u mode, u mt, u bm, u ds, u bfr) -> (AT+CNMI=mode,mt,..)
> - SetSMSC(s smsc) ->
>
> - SMSReceived(u index, s where)(signal)
>
> This is just food for thought, what think about such an API the
> different parties involved?
> I've tried to clarify in parentheses all the methods that might be
> misleading or might be controversial, with either its purpose or the
> correspondent AT command. I think that standard interfaces such as
> {SMS, Contacts}.{Delete, List, Get} should definitely go in. Other
> methods (specially its naming) are somewhat more controversial and
> I'll be happy to discuss 'em.
>
> I've attached this interfaces to the Gsm (WCDMA) part, we still need
> to decide what to do with CDMA... Dan? :)
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: > 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
#include
#include
+#include
+#include
#include
#include
@@ -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&q
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Sat, Aug 2, 2008 at 2:43 PM, Stuart Ward <[EMAIL PROTECTED]> wrote: > The whole point of Network Manager is that it is the integrated network > access tool. Modems are largely standard. we don't need special software to > access different modems. Perhaps we need a configuration strings for some > modems but I see no point in having a separate tool for modems. > > Equally for GSM modems these are as least as standardised as WiFi cards. So > we should not need a seperate tool to manage them. > > What Network Manager should show is the GSM signal strength as soon as you > plug in a modem, and allow a button to select and establish the connection. > Just like the WiFi selection. > > Am I missing something here? This is just a code reorganization, the NetworkManager will still be the frontend for everything. There are no UI or work flow changes caused by this. As I've tried to explain multiple times already, the reorganization was done mainly to support other modem backends that are currently more advanced than what NM has. Modems are very much _not_ standardized for anything except the very basic functionality. Your example (signal strength) is a good one: while not connected, NM does not keep the serial device open just to get the signal strength. While connected through modem though, it depends very much on modem hardware how to do it: Some cards have another serial device for monitoring (some use binary format there, some use AT commands with different formats), some have one multiplexed device. So there needs to be different handling for different cards and providing a plugins framework in ModemManager is exactly for this. The big difference between wifi and modems is that wifi scanning takes less than a second, so we can schedule scans in some intervals. For modems though, scanning takes a long time (over 10 seconds, sometimes even close to a minute for cards which support a wide range of frequencies), so NM can not just randomly block the access to modem for such long periods of time. 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 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: 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
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 Q&A > > 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 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)
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: 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: [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
[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 Q&A 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: [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: 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: 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: 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: [1216898663.617076] >> serial_debug(): Sending: 'ATD*99***1***1# ' >> Jul 24 12:24:23 lapy NetworkManager: [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: 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: [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: [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: 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
