[PATCH] Remove dependency on PolicyKit
The attached patches remove the dependency on PolicyKit by supplying a stubbed-out polkit implementation that allows every request. The change has been split into 2 patches: The first one has no functional changes, and only reorganises the code to consolidate all access to polkit headers into a single file, nm-polkit.h. The second patch implements the configure option and the polkit stubs. The patches are off the NM_0_8 branch, but if you're interested in supporting this configuration and are likely to accept the patch, I will work on a patch for master. 0001-Consolidate-all-access-to-polkit-via-nm-polkit.h.patch Description: Binary data 0002-Configure-option-without-polkit-to-use-a-stubbed-out.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Don't require gettext/intltool if --disable-nls configure option provided.
The attached patch is so that ./configure --disable-nls actually does what it is intended to do -- i.e. remove the dependency on intltool. The patch is off the NM_0_8 branch, but if you like it I can work on a patch for master. 0001-Don-t-require-gettext-intltool-if-disable-nls-config.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Configure option --disable-crashtrace to disable GNU backtrace extensions.
The attached patch provides a configure option to disable GNU backtrace extensions (for non-glibc toolchains). The patch is off the NM_0_8 branch, but if you like it I can work on a patch for master. 0001-Configure-option-disable-crashtrace-to-disable-GNU-b.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] support nl80211
On Wed, 2011-10-05 at 17:40 +0200, Johannes Berg wrote:
This is on top of the nl80211 refactoring branch.
Applied with some fixes, thanks!
Dan
johannes
diff --git a/src/Makefile.am b/src/Makefile.am
index aa14e8c..a225f89 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -124,6 +124,8 @@ NetworkManager_SOURCES = \
wifi-utils-private.h \
wifi-utils-wext.c \
wifi-utils-wext.h \
+ wifi-utils-nl80211.c \
+ wifi-utils-nl80211.h \
nm-device-wifi.c \
nm-device-wifi.h \
nm-device-olpc-mesh.c \
diff --git a/src/nm-netlink-compat.h b/src/nm-netlink-compat.h
index af21fb9..a852928 100644
--- a/src/nm-netlink-compat.h
+++ b/src/nm-netlink-compat.h
@@ -172,6 +172,16 @@ __nl_cache_include (struct nl_cache *cache, struct
nl_object *obj, change_func_t
}
#define nl_cache_include __nl_cache_include
+static inline int __genl_ctrl_alloc_cache(struct nl_sock *h, struct nl_cache
**cache)
+{
+ struct nl_cache *tmp = genl_ctrl_alloc_cache(h);
+ if (!tmp)
+ return -ENOMEM;
+ *cache = tmp;
+ return 0;
+}
+#define genl_ctrl_alloc_cache __genl_ctrl_alloc_cache
+
#define NLE_SUCCESS 0
#define NLE_FAILURE 1
#define NLE_INTR2
diff --git a/src/nm-udev-manager.c b/src/nm-udev-manager.c
index 8bd1294..8b41a55 100644
--- a/src/nm-udev-manager.c
+++ b/src/nm-udev-manager.c
@@ -347,6 +347,12 @@ is_wireless (GUdevDevice *device)
char phy80211_path[255];
struct stat s;
const char *path;
+ const char *tmp;
+
+ /* Check devtype, newer kernels (2.6.32+) have this */
+ tmp = g_udev_device_get_property (device, DEVTYPE);
+ if (g_strcmp0 (tmp, wlan) == 0)
+ return TRUE;
/* Check for nl80211 sysfs paths */
path = g_udev_device_get_sysfs_path (device);
@@ -354,7 +360,7 @@ is_wireless (GUdevDevice *device)
if ((stat (phy80211_path, s) == 0 (s.st_mode S_IFDIR)))
return TRUE;
- /* Otherwise hit up WEXT/nl80211 directly */
+ /* Otherwise hit up WEXT directly */
return wifi_utils_is_wifi (g_udev_device_get_name (device));
}
diff --git a/src/wifi-utils-nl80211.c b/src/wifi-utils-nl80211.c
new file mode 100644
index 000..4b96448
--- /dev/null
+++ b/src/wifi-utils-nl80211.c
@@ -0,0 +1,695 @@
+/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*- */
+/* NetworkManager -- Network link manager
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Copyright (C) 2005 - 2011 Red Hat, Inc.
+ * Copyright (C) 2006 - 2008 Novell, Inc.
+ * Copyright (C) 2011 Intel Corporation. All rights reserved.
+ */
+
+#include config.h
+#include errno.h
+#include string.h
+#include sys/ioctl.h
+#include net/ethernet.h
+#include unistd.h
+#include math.h
+
+#include glib.h
+
+#include netlink/genl/genl.h
+#include netlink/genl/family.h
+#include netlink/genl/ctrl.h
+
+#include linux/nl80211.h
+
+#include wifi-utils-private.h
+#include wifi-utils-nl80211.h
+#include nm-logging.h
+#include nm-utils.h
+#include nm-netlink-compat.h
+
+typedef struct {
+ WifiData parent;
+ struct nl_sock *nl_sock;
+ struct nl_cache *nl_cache;
+ struct genl_family *nl_family;
+ struct nl_cb *nl_cb;
+ guint32 *freqs;
+ int num_freqs;
+} WifiDataNl80211;
+
+static int ack_handler (struct nl_msg *msg, void *arg)
+{
+ int *err = arg;
+ *err = 0;
+ return NL_STOP;
+}
+
+static int finish_handler (struct nl_msg *msg, void *arg)
+{
+ int *ret = arg;
+ *ret = 0;
+ return NL_SKIP;
+}
+
+static int error_handler (struct sockaddr_nl *nla, struct nlmsgerr *err,
+ void *arg)
+{
+ int *ret = arg;
+ *ret = err-error;
+ return NL_SKIP;
+}
+
+static struct nl_msg *nl80211_alloc_msg (WifiDataNl80211 *nl80211,
+ guint32 cmd, guint32 flags)
+{
+ struct nl_msg *msg = nlmsg_alloc ();
+ if (!msg)
+ return NULL;
+
+ genlmsg_put (msg, 0, 0, genl_family_get_id (nl80211-nl_family), 0,
+ flags, cmd, 0);
+
+ NLA_PUT_U32 (msg,
Re: [PATCH 1/2] Use correct g_free() function
On Tue, 2011-10-04 at 22:22 +0200, Thomas Jarosch wrote: Detected by cppcheck. Thanks, applied. Looks like the other two variables there (var1 and var2) also need to be freed with g_free() since they are allocated using glib functions. I've added that to your patch. Dan Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com --- src/settings/plugins/ifcfg-rh/shvar.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/settings/plugins/ifcfg-rh/shvar.c b/src/settings/plugins/ifcfg-rh/shvar.c index c740801..4f8ddd6 100644 --- a/src/settings/plugins/ifcfg-rh/shvar.c +++ b/src/settings/plugins/ifcfg-rh/shvar.c @@ -336,13 +336,13 @@ svSetValue(shvarFile *s, const char *key, const char *value, gboolean verbatim) } end: -if (newval) free(newval); +if (newval) g_free(newval); if (val1) free(val1); if (val2) free(val2); return; bail: -if (keyValue) free (keyValue); +if (keyValue) g_free (keyValue); goto end; } ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 2/2] Fix possible use of uninitialized variable
On Tue, 2011-10-04 at 22:23 +0200, Thomas Jarosch wrote: Detected by cppcheck. Applied, thanks! Dan Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com --- src/settings/plugins/ifnet/net_utils.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/settings/plugins/ifnet/net_utils.c b/src/settings/plugins/ifnet/net_utils.c index 83f86ab..b533ae3 100644 --- a/src/settings/plugins/ifnet/net_utils.c +++ b/src/settings/plugins/ifnet/net_utils.c @@ -313,7 +313,7 @@ is_ip4_address (const char *in_address) gboolean result = FALSE; gchar *tmp; GRegex *regex = g_regex_new (pattern, 0, 0, NULL); - GMatchInfo *match_info; + GMatchInfo *match_info = NULL; if (!address) goto done; ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property
On Mon, Oct 3, 2011 at 7:34 PM, Dan Williams d...@redhat.com wrote: On Sat, 2011-10-01 at 15:45 +0200, Aleksander Morgado wrote: Hey hey, Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE values, and preference of a specific mode is now given in the new PreferredMode property and as an extra argument to the SetAllowedModes() call. * Supported Modes: bitmask specifying which modes are supported by the specific hardware. For example, a modem may only support 1G/2G/3G connections (not 4G). * Allowed Modes: bitmask specifying which modes, of the ones Supported by the modem, are allowed to use. For example, a modem may support 1G/2G/3G connections but only 1G and 2G connections are allowed by the user as 3G involves more expensive data rates. [Allowed] ⊆ [Supported] * Preferred Mode: specific mode which is preferred among the ones defined in the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections but the user would like that if possible 2G be used, as 3G consumes too much battery. If 2G is not possible, 3G can be used. [Preferred] ∈ [Allowed] I don't have a huge objection to this, but I'm not sure I see the benefit of having the Preferred/Allowed split versus the complexity. Basically, if Allowed were an enum where we enumerated the preference there are 4 items to choose from (4G, 3G, 2G, empty) and 3 slots in the preference order (since empty doesn't get a slot, just a single enum). Thats a total of 25 combinations, but some like 2G4G don't really make sense, so we have somewhere under 25. 32-bits gives us a lot of range there if it's an enum not a bitfield. The downside is that it has no relationship with the MM_MODEM_MODE flags. My worry is just that it's added complexity (3 properties to check instead of 2) that may be just a bit more work for clients. I do see problems in both implementations, and I understand that the new one may be more complex, but trying to cope with the addition of 4G to the list is not an easy task, I would say. Yeah, I know. It would be good to check what modes the new LTE devices support. Is there anyone out there who can check this? Do the devices support specifying 'preferred' modes to automatically connect in one mode or another? Unfortunately I don't have any information on this, we'd have to ask contacts at Novatel, Sierra, Qualcomm, etc what the plans are here if we can. Qualcomm chips do have the ability to select a different mode preference, and as far as I can tell from the reverse engineering we've done, it's a gigantic enum for every mode conceivable because they include stuff like WiFi in there too. Think stuff like CDMA/AMPS/HDR/WLAN-only (ie 2G/1G/3G/Wifi only) as a distinct value from HDR/LTE only (ie 3G/4G only). And values for things like anything except WiFi. So you can bet they've added a bunch more options to that enum for LTE. Also, do the 4G devices support complex setups like 3G preferred, and if not available go 4G or 3G preferred, and if not available go 2G. As a user, I think I can find good reasons to need these last two options, not just 3G preferred. Yeah, that's the question... not sure we have an answer yet. But I guess it would be good to be able to do this since we aren't sure. I am trying to figure out some more details on what the Novatel E362 supports. I'll report back to the list. -Jason 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: NM dbus API bug ?
On Tue, 2011-10-04 at 17:07 +0200, Jean Parpaillon wrote: Hi again :) Your original crash is a dbus-glib bug, which likely was a regression in dbus-glib 0.94 and is fixed by: http://cgit.freedesktop.org/dbus/dbus-glib/commit/?id=3e0828f57c3925ea9b63d22ab82d991a0fea0536 ie it's been fixed in dbus-glib 0.96 and later. I'm quite confused on using NetworkManager DBUS API on master branch. 1/ When getting the object with the path returned by NetworkManager.GetDevices() method, NM crashes (path is of the form: /org/freedesktop/NetworkManager/Devices/0) That is the correct form of paths. Device names can change at runtime so they are not part of the object path as exposed over D-Bus. 2/ If I get the Device object with path like /org/freedesktop/NetworkManager/Devices/eth0, I can get the object but Introspectable interface gives me no interface at all on this object. Strange... Right, because that's not actually an object that NetworkManager exports over D-Bus, which is why you won't get any introspection information. It could be a bug in the Python dbus bindings that you get an object here at all, but the Python bits us lazy bindings so they'll only look up the introspection information when you need it, which can be later than when you create the Interface object. In the end, the bug is in dbus-glib 0.94 and fixed in 0.96. Dan It is WIP ? It is supposed to work right now ? I can try to fix it, if someone gives me some hints :) Regards, Jean Le mardi 04 octobre 2011 à 14:15 +0200, Jean Parpaillon a écrit : Hi all, I'm using NetworkManager from master branch. Running the following python code crash NetworkManager: ### import dbus import sys NM_DBUS_SERVICE = org.freedesktop.NetworkManager NM_MANAGER_PATH = /org/freedesktop/NetworkManager NM_MANAGER_IFACE = org.freedesktop.NetworkManager NM_DEVICE_IFACE = org.freedesktop.NetworkManager.Device bus = dbus.SystemBus() manager_proxy = bus.get_object(NM_DBUS_SERVICE, NM_MANAGER_PATH) manager_iface = dbus.Interface(manager_proxy, dbus_interface=NM_MANAGER_IFACE) for device_path in manager_iface.GetDevices(): print Device: %s % device_path device_proxy = bus.get_object(NM_DBUS_SERVICE, device_path) ### In a few words, it crashes when I try to get dbus proxy object with a path I get from GetDevices() method. The crashes produces the following backtrace: Oct 4 14:01:17 tiflis NetworkManager[26393]: warn caught signal 11. Generating backtrace... Oct 4 14:01:17 tiflis NetworkManager[26393]: *** START ** Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 0: /usr/sbin/NetworkManager (nm_logging_backtrace+0x3b) [0x45e3fb] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 1: /usr/sbin/NetworkManager (0x40+0x4470c1) [0x4470c1] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 2: /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fbdf74d9000+0x7fbdf74e8020) [0x7fbdf74e8020] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 3: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf79469b0) [0x7fbdf79469b0] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 4: /lib/libglib-2.0.so.0 (g_hash_table_foreach+0x43) [0x7fbdf6017bd3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 5: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf794808c) [0x7fbdf794808c] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 6: /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fbdf76f5000+0x7fbdf7713371) [0x7fbdf7713371] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 7: /lib/x86_64-linux-gnu/libdbus-1.so.3 (dbus_connection_dispatch+0x380) [0x7fbdf7705270] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 8: /usr/lib/x86_64-linux-gnu/libdbus-glib-1.so.2 (0x7fbdf793a000 +0x7fbdf7945675) [0x7fbdf7945675] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 9: /lib/libglib-2.0.so.0 (g_main_context_dispatch+0x1f3) [0x7fbdf60284a3] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 10: /lib/libglib-2.0.so.0 (0x7fbdf5fe3000+0x7fbdf6028c80) [0x7fbdf6028c80] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 11: /lib/libglib-2.0.so.0 (g_main_loop_run+0x182) [0x7fbdf60292f2] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 12: /usr/sbin/NetworkManager (main+0x1155) [0x4220f5] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xfd) [0x7fbdf57f7ead] Oct 4 14:01:17 tiflis NetworkManager[26393]: Frame 14: /usr/sbin/NetworkManager (0x40+0x42224d) [0x42224d] Oct 4 14:01:17 tiflis NetworkManager[26393]: *** END ** Any clue ? ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property
On Wed, 2011-10-05 at 13:51 -0400, Jason Glasgow wrote: On Mon, Oct 3, 2011 at 7:34 PM, Dan Williams d...@redhat.com wrote: On Sat, 2011-10-01 at 15:45 +0200, Aleksander Morgado wrote: Hey hey, Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE values, and preference of a specific mode is now given in the new PreferredMode property and as an extra argument to the SetAllowedModes() call. * Supported Modes: bitmask specifying which modes are supported by the specific hardware. For example, a modem may only support 1G/2G/3G connections (not 4G). * Allowed Modes: bitmask specifying which modes, of the ones Supported by the modem, are allowed to use. For example, a modem may support 1G/2G/3G connections but only 1G and 2G connections are allowed by the user as 3G involves more expensive data rates. [Allowed] ⊆ [Supported] * Preferred Mode: specific mode which is preferred among the ones defined in the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections but the user would like that if possible 2G be used, as 3G consumes too much battery. If 2G is not possible, 3G can be used. [Preferred] ∈ [Allowed] I don't have a huge objection to this, but I'm not sure I see the benefit of having the Preferred/Allowed split versus the complexity. Basically, if Allowed were an enum where we enumerated the preference there are 4 items to choose from (4G, 3G, 2G, empty) and 3 slots in the preference order (since empty doesn't get a slot, just a single enum). Thats a total of 25 combinations, but some like 2G4G don't really make sense, so we have somewhere under 25. 32-bits gives us a lot of range there if it's an enum not a bitfield. The downside is that it has no relationship with the MM_MODEM_MODE flags. My worry is just that it's added complexity (3 properties to check instead of 2) that may be just a bit more work for clients. I do see problems in both implementations, and I understand that the new one may be more complex, but trying to cope with the addition of 4G to the list is not an easy task, I would say. Yeah, I know. It would be good to check what modes the new LTE devices support. Is there anyone out there who can check this? Do the devices support specifying 'preferred' modes to automatically connect in one mode or another? Unfortunately I don't have any information on this, we'd have to ask contacts at Novatel, Sierra, Qualcomm, etc what the plans are here if we can. Qualcomm chips do have the ability to select a different mode preference, and as far as I can tell from the reverse engineering we've done, it's a gigantic enum for every mode conceivable because they include stuff like WiFi in there too. Think stuff like CDMA/AMPS/HDR/WLAN-only (ie 2G/1G/3G/Wifi only) as a distinct value from HDR/LTE only (ie 3G/4G only). And values for things like anything except WiFi. So you can bet they've added a bunch more options to that enum for LTE. Also, do the 4G devices support complex setups like 3G preferred, and if not available go 4G or 3G preferred, and if not available go 2G. As a user, I think I can find good reasons to need these last two options, not just 3G preferred. Yeah, that's the question... not sure we have an answer yet. But I guess it would be good to be able to do this since we aren't sure. I am trying to figure out some more details on what the Novatel E362 supports. I'll report back to the list. I had that thought too, and looked at the patches, but oddly the patches don't handle LTE at all. It simply uses $NWRAT and only allows setting the allowed mode to GSM preferred, WCDMA preferred, or any, which isn't quite right. Can you ask if there are other modes that NWRAT allows, like restricting to LTE-only, or 3G-preferred? This was another question I had here, given that I thought the E362 was a multi-mode device (ie, LTE + CDMA + UMTS); using WCDMA for this seems
Re: [PATCH 8/8] api: Let MM_MODEM_MODE be a bitfield, and new PreferredMode property
Sure. I've forward this request, as well as a request for full documentation of all the $NW commands to Novatel. -Jason On Wed, Oct 5, 2011 at 3:06 PM, Dan Williams d...@redhat.com wrote: On Wed, 2011-10-05 at 13:51 -0400, Jason Glasgow wrote: On Mon, Oct 3, 2011 at 7:34 PM, Dan Williams d...@redhat.com wrote: On Sat, 2011-10-01 at 15:45 +0200, Aleksander Morgado wrote: Hey hey, Supported and Allowed modes are modified to be bitmasks of MM_MODEM_MODE values, and preference of a specific mode is now given in the new PreferredMode property and as an extra argument to the SetAllowedModes() call. * Supported Modes: bitmask specifying which modes are supported by the specific hardware. For example, a modem may only support 1G/2G/3G connections (not 4G). * Allowed Modes: bitmask specifying which modes, of the ones Supported by the modem, are allowed to use. For example, a modem may support 1G/2G/3G connections but only 1G and 2G connections are allowed by the user as 3G involves more expensive data rates. [Allowed] ⊆ [Supported] * Preferred Mode: specific mode which is preferred among the ones defined in the Allowed modes bitmask. For example, a modem may allow 1G/2G/3G connections but the user would like that if possible 2G be used, as 3G consumes too much battery. If 2G is not possible, 3G can be used. [Preferred] ∈ [Allowed] I don't have a huge objection to this, but I'm not sure I see the benefit of having the Preferred/Allowed split versus the complexity. Basically, if Allowed were an enum where we enumerated the preference there are 4 items to choose from (4G, 3G, 2G, empty) and 3 slots in the preference order (since empty doesn't get a slot, just a single enum). Thats a total of 25 combinations, but some like 2G4G don't really make sense, so we have somewhere under 25. 32-bits gives us a lot of range there if it's an enum not a bitfield. The downside is that it has no relationship with the MM_MODEM_MODE flags. My worry is just that it's added complexity (3 properties to check instead of 2) that may be just a bit more work for clients. I do see problems in both implementations, and I understand that the new one may be more complex, but trying to cope with the addition of 4G to the list is not an easy task, I would say. Yeah, I know. It would be good to check what modes the new LTE devices support. Is there anyone out there who can check this? Do the devices support specifying 'preferred' modes to automatically connect in one mode or another? Unfortunately I don't have any information on this, we'd have to ask contacts at Novatel, Sierra, Qualcomm, etc what the plans are here if we can. Qualcomm chips do have the ability to select a different mode preference, and as far as I can tell from the reverse engineering we've done, it's a gigantic enum for every mode conceivable because they include stuff like WiFi in there too. Think stuff like CDMA/AMPS/HDR/WLAN-only (ie 2G/1G/3G/Wifi only) as a distinct value from HDR/LTE only (ie 3G/4G only). And values for things like anything except WiFi. So you can bet they've added a bunch more options to that enum for LTE. Also, do the 4G devices support complex setups like 3G preferred, and if not available go 4G or 3G preferred, and if not available go 2G. As a user, I think I can find good reasons to need these last two options, not just 3G preferred. Yeah, that's the question... not sure we have an answer yet. But I guess it would be good to be able to do this since we aren't sure. I am trying to figure out some more details on what the Novatel E362 supports. I'll report back to the list. I had that thought too, and looked at the patches, but oddly the patches don't handle LTE at all. It simply uses $NWRAT and only allows setting the allowed mode to GSM preferred, WCDMA preferred, or any, which isn't quite right. Can you ask if there are
Re: [PATCH 1/2] Use correct g_free() function
On 10/05/2011 07:40 PM, Dan Williams wrote: On Tue, 2011-10-04 at 22:22 +0200, Thomas Jarosch wrote: Detected by cppcheck. Thanks, applied. Looks like the other two variables there (var1 and var2) also need to be freed with g_free() since they are allocated using glib functions. I've added that to your patch. Yes, very true. I've isolated the logic of this code and reported it to the cppcheck project. Thanks! Thomas ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: nm_setting_gsm_get_pin() retuns null
Thanks for that thorough explanation. However, I wonder if there isn't a
race condition in that implementation: if we request all three
properties in gsm_device_added(), can we be certain that we have all of
them once we are in sim_id_reply()? Isn't there a risk that
sim_id_reply() might be called back before unlock_reply()?
Anders Feder
On 03-10-2011 23:18, Dan Williams wrote:
On Mon, 2011-10-03 at 14:20 +0200, Anders Feder wrote:
Where would you propose the new code be added?
In the first iteration, I imagine it would work something like this:
If (UnlockRequired)
Get SimIdentifier
If (SimIdentifier is found)
Get PIN for SimIdentifier from keyring
If (PIN is found for SimIdentifier)
Try unlock using saved PIN
While (unlock failed)
Prompt user for new PIN
Try unlock using new PIN
If (unlock succeeded)
Save new PIN for SimIdentifier to keyring
If this works, a similar procedure could be applied for
DeviceIdentifier, if SimIdentifier is not found.
Is this the best approach?
Yeah, that's basically it. So UnlockRequired and DeviceIdentifier are
both properties of the org.freedesktop.ModemManager.Modem interface, and
thus you can retrieve them both in the same D-Bus properties call using
GetAll(). For that, in src/applet-device-gsm.c's gsm_device_added()
function, where it calls the Get() method with UnlockRequired, what you
want to do is call GetAll instead and kill the UnlockRequired
argument. Then in the unlock_reply() for the dbus_g_proxy_end_call()
you'll do something like:
GHashTable *props = NULL;
if (dbus_g_proxy_end_call (proxy, call,error,
DBUS_TYPE_G_MAP_OF_VARIANT,props,
G_TYPE_INVALID)) {
GHashTableIter iter;
const char *prop_name;
GValue *value;
g_hash_table_iter_init (iter, props);
while (g_hash_table_iter_next (iter, (gpointer)prop_name,
(gpointer)value)) {
if ((strcmp (prop_name, UnlockRequired) == 0)
G_VALUE_HOLDS_STRING (value)) {
g_free (info-unlock_required);
info-unlock_required = parse_unlock_required (value);
}
if ((strcmp (prop_name, DeviceIdentifier) == 0)
G_VALUE_HOLDS_STRING (value)) {
g_free (info-devid);
info-devid = g_value_dup_string (value);
}
}
}
That takes care of the UnlockRequired and DeviceIdentifier properties.
Now you need to get the SimIdentifier property, which is a GSM-specific
property (unlike UnlockRequired and DeviceIdentifier which are provided
for CDMA devices too). For that you'll want to do something like this
in gsm_device_added():
dbus_g_proxy_begin_call (info-props_proxy, Get,
sim_id_reply, info, NULL,
G_TYPE_STRING,
MM_DBUS_INTERFACE_MODEM_GSM_CARD,
G_TYPE_STRING, SimIdentifier,
G_TYPE_INVALID);
and then basically copy paste the current unlock_reply() function as
sim_id_reply(), fix up the property stuff there (obviously you're
handling the SimIdentifier property instead of UnlockRequired) and then
at the end of that function, you want something like this:
if (info-unlock_required (info-simid || info-devid))
unlock_dialog_new (info-device, info);
which will actually do the unlock. You dont' want to call
unlock_dialog_new() in unlock_reply() because you don't have the
SimIdentifier yet.
Then unlock_dialog_new() is where you'd query the keyring for existing
PINs using SimIdentifier as one of the attributes the PIN would be
stored with (using gnome_keyring_find_itemsv_sync()) and if there wasn't
any result try again with DeviceIdentifier. Check out utils/utils.c and
src/applet-agent.c for more examples of how to write and read items from
the keyring.
Dan
Anders Feder
On 03-10-2011 06:00, Dan Williams wrote:
On Sat, 2011-10-01 at 02:41 +0200, Anders Feder wrote:
Thanks. I've left you a question in the bug report. I may be
interested in taking a stab at this if it isn't overwhelmingly
difficult.
Responded. It shouldn't be too difficult; there's already code there to
track the modem object from ModemManager and do the right thing. So in
addition to the UnlockRequired property, you'd also want to grab and
watch the SimIdentifier and DeviceIdentifier properties, and use those
to look in the keyring for the right PIN.
Dan
Anders Feder
On 30-09-2011 07:31, Dan Williams wrote:
On Wed, 2011-09-21 at 08:34 +0200, Anders Feder wrote:
Hi,
I'm trying to write a fix for this bug. I've been experimenting with
testing whether a given connection is configured to autoconnect, using
this code (inside applet-device-gsm.c):
NMSettingConnection *setting =
nm_connection_get_setting_connection (connection);
NMSettingGsm *setting_gsm =
Re: nm_setting_gsm_get_pin() retuns null
On Wed, 2011-10-05 at 22:12 +0200, Anders Feder wrote:
Thanks for that thorough explanation. However, I wonder if there isn't a
race condition in that implementation: if we request all three
properties in gsm_device_added(), can we be certain that we have all of
them once we are in sim_id_reply()? Isn't there a risk that
sim_id_reply() might be called back before unlock_reply()?
Yes, a small risk. This can be alleviated by doing some logic in both
functions and tracking in the 'info' struct whether we've gotten replies
for both the initial modem properties and the initial card properties,
and then only doing the unlock dialog when both of those are true AND
the other stuff I wrote was true, and doing that check from both places.
It just means more variables.
Dan
Anders Feder
On 03-10-2011 23:18, Dan Williams wrote:
On Mon, 2011-10-03 at 14:20 +0200, Anders Feder wrote:
Where would you propose the new code be added?
In the first iteration, I imagine it would work something like this:
If (UnlockRequired)
Get SimIdentifier
If (SimIdentifier is found)
Get PIN for SimIdentifier from keyring
If (PIN is found for SimIdentifier)
Try unlock using saved PIN
While (unlock failed)
Prompt user for new PIN
Try unlock using new PIN
If (unlock succeeded)
Save new PIN for SimIdentifier to keyring
If this works, a similar procedure could be applied for
DeviceIdentifier, if SimIdentifier is not found.
Is this the best approach?
Yeah, that's basically it. So UnlockRequired and DeviceIdentifier are
both properties of the org.freedesktop.ModemManager.Modem interface, and
thus you can retrieve them both in the same D-Bus properties call using
GetAll(). For that, in src/applet-device-gsm.c's gsm_device_added()
function, where it calls the Get() method with UnlockRequired, what you
want to do is call GetAll instead and kill the UnlockRequired
argument. Then in the unlock_reply() for the dbus_g_proxy_end_call()
you'll do something like:
GHashTable *props = NULL;
if (dbus_g_proxy_end_call (proxy, call,error,
DBUS_TYPE_G_MAP_OF_VARIANT,props,
G_TYPE_INVALID)) {
GHashTableIter iter;
const char *prop_name;
GValue *value;
g_hash_table_iter_init (iter, props);
while (g_hash_table_iter_next (iter, (gpointer)prop_name,
(gpointer)value)) {
if ((strcmp (prop_name, UnlockRequired) == 0)
G_VALUE_HOLDS_STRING (value)) {
g_free (info-unlock_required);
info-unlock_required = parse_unlock_required (value);
}
if ((strcmp (prop_name, DeviceIdentifier) == 0)
G_VALUE_HOLDS_STRING (value)) {
g_free (info-devid);
info-devid = g_value_dup_string (value);
}
}
}
That takes care of the UnlockRequired and DeviceIdentifier properties.
Now you need to get the SimIdentifier property, which is a GSM-specific
property (unlike UnlockRequired and DeviceIdentifier which are provided
for CDMA devices too). For that you'll want to do something like this
in gsm_device_added():
dbus_g_proxy_begin_call (info-props_proxy, Get,
sim_id_reply, info, NULL,
G_TYPE_STRING,
MM_DBUS_INTERFACE_MODEM_GSM_CARD,
G_TYPE_STRING, SimIdentifier,
G_TYPE_INVALID);
and then basically copy paste the current unlock_reply() function as
sim_id_reply(), fix up the property stuff there (obviously you're
handling the SimIdentifier property instead of UnlockRequired) and then
at the end of that function, you want something like this:
if (info-unlock_required (info-simid || info-devid))
unlock_dialog_new (info-device, info);
which will actually do the unlock. You dont' want to call
unlock_dialog_new() in unlock_reply() because you don't have the
SimIdentifier yet.
Then unlock_dialog_new() is where you'd query the keyring for existing
PINs using SimIdentifier as one of the attributes the PIN would be
stored with (using gnome_keyring_find_itemsv_sync()) and if there wasn't
any result try again with DeviceIdentifier. Check out utils/utils.c and
src/applet-agent.c for more examples of how to write and read items from
the keyring.
Dan
Anders Feder
On 03-10-2011 06:00, Dan Williams wrote:
On Sat, 2011-10-01 at 02:41 +0200, Anders Feder wrote:
Thanks. I've left you a question in the bug report. I may be
interested in taking a stab at this if it isn't overwhelmingly
difficult.
Responded. It shouldn't be too difficult; there's already code there to
track the modem object from ModemManager and do the right thing. So in
addition to the UnlockRequired
Re: nm_setting_gsm_get_pin() retuns null
On Wed, 2011-10-05 at 23:21 +0200, Anders Feder wrote:
Alternatively, can I simply request SimIdentifier from unlock_reply()
instead of gsm_device_added()? That way sim_id_reply() won't be invoked
unless unlock_reply() has already completed.
You could chain them together that way, yes, if you moved the stuff from
gsm_device_added() up into unlock_reply() where you get a successful
reply for DeviceIdentifier.
Dan
Anders Feder
On 05-10-2011 22:45, Dan Williams wrote:
On Wed, 2011-10-05 at 22:12 +0200, Anders Feder wrote:
Thanks for that thorough explanation. However, I wonder if there isn't a
race condition in that implementation: if we request all three
properties in gsm_device_added(), can we be certain that we have all of
them once we are in sim_id_reply()? Isn't there a risk that
sim_id_reply() might be called back before unlock_reply()?
Yes, a small risk. This can be alleviated by doing some logic in both
functions and tracking in the 'info' struct whether we've gotten replies
for both the initial modem properties and the initial card properties,
and then only doing the unlock dialog when both of those are true AND
the other stuff I wrote was true, and doing that check from both places.
It just means more variables.
Dan
Anders Feder
On 03-10-2011 23:18, Dan Williams wrote:
On Mon, 2011-10-03 at 14:20 +0200, Anders Feder wrote:
Where would you propose the new code be added?
In the first iteration, I imagine it would work something like this:
If (UnlockRequired)
Get SimIdentifier
If (SimIdentifier is found)
Get PIN for SimIdentifier from keyring
If (PIN is found for SimIdentifier)
Try unlock using saved PIN
While (unlock failed)
Prompt user for new PIN
Try unlock using new PIN
If (unlock succeeded)
Save new PIN for SimIdentifier to keyring
If this works, a similar procedure could be applied for
DeviceIdentifier, if SimIdentifier is not found.
Is this the best approach?
Yeah, that's basically it. So UnlockRequired and DeviceIdentifier are
both properties of the org.freedesktop.ModemManager.Modem interface, and
thus you can retrieve them both in the same D-Bus properties call using
GetAll(). For that, in src/applet-device-gsm.c's gsm_device_added()
function, where it calls the Get() method with UnlockRequired, what you
want to do is call GetAll instead and kill the UnlockRequired
argument. Then in the unlock_reply() for the dbus_g_proxy_end_call()
you'll do something like:
GHashTable *props = NULL;
if (dbus_g_proxy_end_call (proxy, call,error,
DBUS_TYPE_G_MAP_OF_VARIANT,props,
G_TYPE_INVALID)) {
GHashTableIter iter;
const char *prop_name;
GValue *value;
g_hash_table_iter_init (iter, props);
while (g_hash_table_iter_next (iter, (gpointer)prop_name,
(gpointer)value)) {
if ((strcmp (prop_name, UnlockRequired) == 0)
G_VALUE_HOLDS_STRING (value)) {
g_free (info-unlock_required);
info-unlock_required = parse_unlock_required (value);
}
if ((strcmp (prop_name, DeviceIdentifier) == 0)
G_VALUE_HOLDS_STRING (value)) {
g_free (info-devid);
info-devid = g_value_dup_string (value);
}
}
}
That takes care of the UnlockRequired and DeviceIdentifier properties.
Now you need to get the SimIdentifier property, which is a GSM-specific
property (unlike UnlockRequired and DeviceIdentifier which are provided
for CDMA devices too). For that you'll want to do something like this
in gsm_device_added():
dbus_g_proxy_begin_call (info-props_proxy, Get,
sim_id_reply, info, NULL,
G_TYPE_STRING,
MM_DBUS_INTERFACE_MODEM_GSM_CARD,
G_TYPE_STRING, SimIdentifier,
G_TYPE_INVALID);
and then basically copy paste the current unlock_reply() function as
sim_id_reply(), fix up the property stuff there (obviously you're
handling the SimIdentifier property instead of UnlockRequired) and then
at the end of that function, you want something like this:
if (info-unlock_required (info-simid || info-devid))
unlock_dialog_new (info-device, info);
which will actually do the unlock. You dont' want to call
unlock_dialog_new() in unlock_reply() because you don't have the
SimIdentifier yet.
Then unlock_dialog_new() is where you'd query the keyring for existing
PINs using SimIdentifier as one of the attributes the PIN would be
stored with (using gnome_keyring_find_itemsv_sync()) and if there wasn't
any result try again with DeviceIdentifier. Check out utils/utils.c and
src/applet-agent.c for
Re: DHCP timeout on ethernet device.
On Tue, 2011-10-04 at 11:44 +0200, Jiri Popelka wrote: You can add timeout value; to /etc/dhcp/dhclient-interface.conf See also http://mail.gnome.org/archives/networkmanager-list/2011-September/msg00127.html That doesn't work because NM bounds the DHCP transaction and kills it if it runs over 45 seconds. The better question is: why is DHCP on that network taking so long? I've talked about bumping the timeout to 60 seconds before, but the point here is that if your network is taking more than 60 seconds to respond to DHCP requests, something is *really*, *really* wrong, and should be corrected on the network side instead of working around this in the client. How long is the DHCP transaction taking? Dan - Jiri On 10/04/2011 10:24 AM, Anders Gnistrup wrote: Hi I have searched the net and the only method to set the DHCP request timeout value is to change the code. /NetworkManager/src/dhcp-manager/nm-dhcp-manager.c:#define NM_DHCP_TIMEOUT 45 /* DHCP timeout, in seconds */ But that it not a good solution. It there configuration option in the DBUS interface or keyfile that can be set? My own answer is No, it has to done in code. /AG ___ 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] Configure option --disable-crashtrace to disable GNU backtrace extensions.
On Wed, 2011-10-05 at 17:22 +0100, David Röthlisberger wrote: The attached patch provides a configure option to disable GNU backtrace extensions (for non-glibc toolchains). The patch is off the NM_0_8 branch, but if you like it I can work on a patch for master. Thanks, applied to both 0.8 and 0.9. In 0.8 though, we can't simply check for ENABLE_CRASHTRACE in nm-utils.h, because it'll never be TRUE/1. That's because we can't include config.h there, because nm-utils.h is a distributed header and config.h is build-time only. So your patch there effectively disabled it always. However, nm_print_backtrace() was pointless and thus I've deprecated it and removed the implementation from nm-utils.h on the 0.8 branch. It's already gone in 0.9. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
