NM 0.9 asks for PK auth without need
Hi,
802.11x connections that are configured to always prompt for the
password also always require polkit authentication (bgo#646187).
I tried to find out why but got stuck. AFAICS one culprit is
has_system_secrets() in src/settings/nm-agent-manager.c. It iterates
over all properties of a connection and checks whether the flags are
NM_SETTING_SECRET_FLAG_NONE. Of course the flags for 'password'
don't match but since the iterates goes over all properties, others
like 'psk' are at their default value which happens to be
NM_SETTING_SECRET_FLAG_NONE too. So has_system_secrets() always
returns true.
I suppose there needs to be a set_secrets_not_required() call
somewhere to indicate that the other potential secrets actually do
not apply to this connection. Alternatively an extra flag != NONE
could be set explicitly to indicate system secrets.
Suppose that bug is fixed and NM rightfully choses that code path
the PK popup at that point would be still annyoing. It's there to
avoid leaking system stored secrets to the user's agent. What are
those secrets needed for in the user's agent anyways though?
After hacking has_system_secrets() to always return false still the
attached patch is needed to make NM take the supplied secrets.
Btw, why does NM actually distinguish agent owned and not saved?
Shouldn't that decision just be left to the user's agent? The user
agent could lie about where it got the secret from anyways.
Btw2, for 802.1x it would make sense to also not store the user name
globally.
cu
Ludwig
--
(o_ Ludwig Nussel
//\
V_/_ http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
16746 (AG Nürnberg)
From b2a51325d95ad89bea62bed5cce63c1290a2f92d Mon Sep 17 00:00:00 2001
From: Ludwig Nussel ludwig.nus...@suse.de
Date: Tue, 27 Sep 2011 12:34:11 +0200
Subject: [PATCH] treat not saved secrets just like agent owned when cleaning
---
src/settings/nm-settings-connection.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/settings/nm-settings-connection.c b/src/settings/nm-settings-connection.c
index cdad832..4cd9395 100644
--- a/src/settings/nm-settings-connection.c
+++ b/src/settings/nm-settings-connection.c
@@ -592,7 +592,7 @@ clear_nonagent_secrets (GHashTableIter *iter,
NMSettingSecretFlags flags,
gpointer user_data)
{
- if (flags != NM_SETTING_SECRET_FLAG_AGENT_OWNED)
+ if (!(flags (NM_SETTING_SECRET_FLAG_AGENT_OWNED | NM_SETTING_SECRET_FLAG_NOT_SAVED)))
g_hash_table_iter_remove (iter);
return TRUE;
}
--
1.7.3.4
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] clean up mobile broadband wizard
Hi,
I noticed many duplicate buttons and page headers in the mobile
broadband wizard, attached is a patch that fixes this.
Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93
From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
Subject: Clean up the duplicate titles and buttons from the mobile wizard intro
Bug-Ubuntu: http://bugs.launchpad.net/bugs/856785
The mobile wizard intro page would show all titles duplicated on the left pane,
as well as a bunch of extra, unnecessary buttons (like Go Back...). Clear this
up by using gtk_widget_show() while building the page so the title shows up
when the wizard is started, and call gtk_widget_show_all() in the callback
for the prepare signal so that all the contained widgets are displayed when
the user actually gets to that page.
Index: network-manager-applet-0.9.1.90/src/libnm-gtk/nm-mobile-wizard.c
===
--- network-manager-applet-0.9.1.90.orig/src/libnm-gtk/nm-mobile-wizard.c 2011-08-26 16:38:33.0 -0400
+++ network-manager-applet-0.9.1.90/src/libnm-gtk/nm-mobile-wizard.c 2011-09-22 16:19:04.188449031 -0400
@@ -258,13 +258,13 @@
gtk_box_pack_start (GTK_BOX (vbox), alignment, FALSE, FALSE, 6);
}
- gtk_widget_show_all (vbox);
+ gtk_widget_show (vbox);
self-confirm_idx = gtk_assistant_append_page (GTK_ASSISTANT (self-assistant), vbox);
gtk_assistant_set_page_title (GTK_ASSISTANT (self-assistant),
vbox, _(Confirm Mobile Broadband Settings));
- gtk_assistant_set_page_complete (GTK_ASSISTANT (self-assistant), vbox, TRUE);
gtk_assistant_set_page_type (GTK_ASSISTANT (self-assistant), vbox, GTK_ASSISTANT_PAGE_CONFIRM);
+ gtk_assistant_set_page_complete (GTK_ASSISTANT (self-assistant), vbox, TRUE);
self-confirm_page = vbox;
}
@@ -531,10 +531,10 @@
gtk_box_pack_start (GTK_BOX (hbox), label, FALSE, TRUE, 0);
gtk_box_pack_start (GTK_BOX (vbox), hbox, FALSE, FALSE, 0);
+ gtk_widget_show (vbox);
self-plan_idx = gtk_assistant_append_page (GTK_ASSISTANT (self-assistant), vbox);
gtk_assistant_set_page_title (GTK_ASSISTANT (self-assistant), vbox, _(Choose your Billing Plan));
gtk_assistant_set_page_type (GTK_ASSISTANT (self-assistant), vbox, GTK_ASSISTANT_PAGE_CONTENT);
- gtk_widget_show_all (vbox);
self-plan_page = vbox;
}
@@ -826,10 +826,10 @@
if (self-method_type != NMN_MOBILE_ACCESS_METHOD_TYPE_UNKNOWN)
gtk_widget_hide (self-provider_unlisted_type_combo);
+ gtk_widget_show (vbox);
self-providers_idx = gtk_assistant_append_page (GTK_ASSISTANT (self-assistant), vbox);
gtk_assistant_set_page_title (GTK_ASSISTANT (self-assistant), vbox, _(Choose your Provider));
gtk_assistant_set_page_type (GTK_ASSISTANT (self-assistant), vbox, GTK_ASSISTANT_PAGE_CONTENT);
- gtk_widget_show_all (vbox);
self-providers_page = vbox;
}
@@ -1141,11 +1141,11 @@
gtk_container_add (GTK_CONTAINER (alignment), scroll);
gtk_box_pack_start (GTK_BOX (vbox), alignment, TRUE, TRUE, 6);
+ gtk_widget_show (vbox);
self-country_idx = gtk_assistant_append_page (GTK_ASSISTANT (self-assistant), vbox);
gtk_assistant_set_page_title (GTK_ASSISTANT (self-assistant), vbox, _(Choose your Provider's Country or Region));
gtk_assistant_set_page_type (GTK_ASSISTANT (self-assistant), vbox, GTK_ASSISTANT_PAGE_CONTENT);
gtk_assistant_set_page_complete (GTK_ASSISTANT (self-assistant), vbox, TRUE);
- gtk_widget_show_all (vbox);
self-country_page = vbox;
@@ -1455,13 +1455,13 @@
intro_add_initial_devices (self);
}
- gtk_widget_show_all (vbox);
+ gtk_widget_show (vbox);
gtk_assistant_append_page (GTK_ASSISTANT (self-assistant), vbox);
gtk_assistant_set_page_title (GTK_ASSISTANT (self-assistant),
vbox, _(Set up a Mobile Broadband Connection));
- gtk_assistant_set_page_complete (GTK_ASSISTANT (self-assistant), vbox, TRUE);
gtk_assistant_set_page_type (GTK_ASSISTANT (self-assistant), vbox, GTK_ASSISTANT_PAGE_INTRO);
+ gtk_assistant_set_page_complete (GTK_ASSISTANT (self-assistant), vbox, TRUE);
}
/**/
@@ -1491,6 +1491,8 @@
{
NMAMobileWizard *self = user_data;
+ gtk_widget_show_all (page);
+
if (page != self-providers_page)
remove_provider_focus_idle (self);
if (page != self-country_page)
@@ -1635,6 +1637,8 @@
g_signal_connect (self-assistant, cancel, G_CALLBACK (assistant_cancel), self);
g_signal_connect (self-assistant, prepare, G_CALLBACK (assistant_prepare), self);
+ gtk_assistant_update_buttons_state (GTK_ASSISTANT (self-assistant));
+
/* Run the wizard */
if (parent)
gtk_window_set_transient_for (GTK_WINDOW (self-assistant), parent);
@@ -1654,7 +1658,6 @@
g_return_if_fail (self != NULL);
gtk_window_present (GTK_WINDOW (self-assistant));
- gtk_widget_show_all (self-assistant);
}
void
[PATCH] default VPN import/export path to home directory
Hi,
In previous versions of nm-applet on Ubuntu we could notice the
default path for import and export of VPN configs being the user's
home directory.
Looking again, this doesn't appear to be the case in Oneiric, possibly
because of changes in GTK. The attached patch defines the current
directory as the user's home when
the file chooser is being created for import and export.
Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93
From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
Subject: Select the user's home directory by default as path for import/export
Bug-Ubuntu: http://bugs.launchpad.net/bugs/634913
It makes it one fewer click for most use cases when trying to import or export
a connection; since the home directory is the most likely place to find a
connection to import, or where to drop the file.
Index: network-manager-applet-0.9.1.90/src/connection-editor/vpn-helpers.c
===
--- network-manager-applet-0.9.1.90.orig/src/connection-editor/vpn-helpers.c 2011-07-27 12:10:41.0 -0400
+++ network-manager-applet-0.9.1.90/src/connection-editor/vpn-helpers.c 2011-09-20 16:22:16.054655325 -0400
@@ -257,6 +257,7 @@
{
GtkWidget *dialog;
ActionInfo *info;
+ const char *home_folder;
dialog = gtk_file_chooser_dialog_new (_(Select file to import),
NULL,
@@ -264,6 +265,9 @@
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_OPEN, GTK_RESPONSE_ACCEPT,
NULL);
+home_folder = g_get_home_dir ();
+gtk_file_chooser_set_current_folder (GTK_FILE_CHOOSER (dialog), home_folder);
+
info = g_malloc0 (sizeof (ActionInfo));
info-callback = callback;
info-user_data = user_data;
@@ -373,6 +377,7 @@
NMVpnPluginUiInterface *plugin;
NMSettingVPN *s_vpn = NULL;
const char *service_type;
+ const char *home_folder;
s_vpn = NM_SETTING_VPN (nm_connection_get_setting (connection, NM_TYPE_SETTING_VPN));
service_type = s_vpn ? nm_setting_vpn_get_service_type (s_vpn) : NULL;
@@ -388,6 +393,8 @@
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL,
GTK_STOCK_SAVE, GTK_RESPONSE_ACCEPT,
NULL);
+ home_folder = g_get_home_dir ();
+ gtk_file_chooser_set_current_folder (GTK_FILE_CHOOSER (dialog), home_folder);
plugin = vpn_get_plugin_by_service (service_type);
if (plugin) {
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 0/3] clean up config file handling
Split config file reading and handling out of main.c so that it's easier to extend later on. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] clean up mobile broadband wizard
On Tue, 2011-09-27 at 10:00 -0400, Mathieu Trudel-Lapierre wrote: Hi, I noticed many duplicate buttons and page headers in the mobile broadband wizard, attached is a patch that fixes this. It was a bug in GTK+, which I fixed in time for GNOME 3.2 last week. Cheers ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/3] core: remove unused arguments from nm_manager_get()
They weren't used.
---
src/main.c|2 --
src/nm-device-olpc-mesh.c |6 +++---
src/nm-manager.c |5 -
src/nm-manager.h |2 --
4 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/src/main.c b/src/main.c
index 328c253..a9ffd38 100644
--- a/src/main.c
+++ b/src/main.c
@@ -718,8 +718,6 @@ main (int argc, char *argv[])
}
manager = nm_manager_get (settings,
- config,
- plugins,
state_file,
net_enabled,
wifi_enabled,
diff --git a/src/nm-device-olpc-mesh.c b/src/nm-device-olpc-mesh.c
index ae14279..2f130b1 100644
--- a/src/nm-device-olpc-mesh.c
+++ b/src/nm-device-olpc-mesh.c
@@ -653,7 +653,7 @@ dispose (GObject *object)
device_cleanup (self);
- manager = nm_manager_get (NULL, NULL, NULL, NULL, FALSE, FALSE, FALSE,
FALSE, NULL);
+ manager = nm_manager_get (NULL, NULL, FALSE, FALSE, FALSE, FALSE, NULL);
if (priv-device_added_id)
g_signal_handler_disconnect (manager, priv-device_added_id);
g_object_unref (manager);
@@ -852,7 +852,7 @@ is_companion (NMDeviceOlpcMesh *self, NMDevice *other)
priv-companion = other;
/* When we've found the companion, stop listening for other devices */
- manager = nm_manager_get (NULL, NULL, NULL, NULL, FALSE, FALSE, FALSE,
FALSE, NULL);
+ manager = nm_manager_get (NULL, NULL, FALSE, FALSE, FALSE, FALSE, NULL);
if (priv-device_added_id) {
g_signal_handler_disconnect (manager, priv-device_added_id);
priv-device_added_id = 0;
@@ -907,7 +907,7 @@ check_companion_cb (gpointer user_data)
if (priv-device_added_id != 0)
return FALSE;
- manager = nm_manager_get (NULL, NULL, NULL, NULL, FALSE, FALSE, FALSE,
FALSE, NULL);
+ manager = nm_manager_get (NULL, NULL, FALSE, FALSE, FALSE, FALSE, NULL);
priv-device_added_id = g_signal_connect (manager, device-added,
G_CALLBACK (device_added_cb),
self);
diff --git a/src/nm-manager.c b/src/nm-manager.c
index 9200f34..c74bccb 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -196,7 +196,6 @@ typedef struct {
} RadioState;
typedef struct {
- char *config_file;
char *state_file;
GSList *devices;
@@ -3044,8 +3043,6 @@ out:
NMManager *
nm_manager_get (NMSettings *settings,
-const char *config_file,
-const char *plugins,
const char *state_file,
gboolean initial_net_enabled,
gboolean initial_wifi_enabled,
@@ -3081,7 +3078,6 @@ nm_manager_get (NMSettings *settings,
priv-settings = g_object_ref (settings);
- priv-config_file = g_strdup (config_file);
priv-state_file = g_strdup (state_file);
priv-net_enabled = initial_net_enabled;
@@ -3168,7 +3164,6 @@ dispose (GObject *object)
}
g_free (priv-hostname);
- g_free (priv-config_file);
g_object_unref (priv-settings);
diff --git a/src/nm-manager.h b/src/nm-manager.h
index 22bfca9..afadba2 100644
--- a/src/nm-manager.h
+++ b/src/nm-manager.h
@@ -68,8 +68,6 @@ typedef struct {
GType nm_manager_get_type (void);
NMManager *nm_manager_get (NMSettings *settings,
- const char *config_file,
- const char *plugins,
const char *state_file,
gboolean initial_net_enabled,
gboolean initial_wifi_enabled,
--
1.7.6.2
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 2/3] core: split out config file handling
Make config file stuff somewhat clearer and easier to understand,
and possibly easier to extend later.
---
src/Makefile.am|2 +
src/main.c | 135 +
src/nm-config.c| 243
src/nm-config.h| 55 ++
src/settings/nm-settings.c | 22 ++--
src/settings/nm-settings.h |2 +-
6 files changed, 335 insertions(+), 124 deletions(-)
create mode 100644 src/nm-config.c
create mode 100644 src/nm-config.h
diff --git a/src/Makefile.am b/src/Makefile.am
index c8caefb..cbcfdc6 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -142,6 +142,8 @@ NetworkManager_SOURCES = \
nm-ip6-config.h \
nm-active-connection.h \
nm-active-connection.c \
+ nm-config.h \
+ nm-config.c \
main.c \
nm-policy.c \
nm-policy.h \
diff --git a/src/main.c b/src/main.c
index a9ffd38..8d37bc9 100644
--- a/src/main.c
+++ b/src/main.c
@@ -50,14 +50,13 @@
#include nm-vpn-manager.h
#include nm-logging.h
#include nm-policy-hosts.h
+#include nm-config.h
#if !defined(NM_DIST_VERSION)
# define NM_DIST_VERSION VERSION
#endif
#define NM_DEFAULT_PID_FILE LOCALSTATEDIR/run/NetworkManager.pid
-#define NM_DEFAULT_SYSTEM_CONF_FILE
SYSCONFDIR/NetworkManager/NetworkManager.conf
-#define NM_OLD_SYSTEM_CONF_FILE
SYSCONFDIR/NetworkManager/nm-system-settings.conf
#define NM_DEFAULT_SYSTEM_STATE_FILE
LOCALSTATEDIR/lib/NetworkManager/NetworkManager.state
/*
@@ -310,46 +309,6 @@ done:
}
static gboolean
-parse_config_file (const char *filename,
- char **plugins,
- char **dhcp_client,
- char ***dns_plugins,
- char **log_level,
- char **log_domains,
- GError **error)
-{
- GKeyFile *config;
- gboolean success = FALSE;
-
- config = g_key_file_new ();
- if (!config) {
- g_set_error (error, 0, 0,
-Not enough memory to load config file.);
- return FALSE;
- }
-
- g_key_file_set_list_separator (config, ',');
- if (!g_key_file_load_from_file (config, filename, G_KEY_FILE_NONE,
error))
- goto out;
-
- *plugins = g_key_file_get_value (config, main, plugins, error);
- if (*error)
- goto out;
-
- *dhcp_client = g_key_file_get_value (config, main, dhcp, NULL);
- *dns_plugins = g_key_file_get_string_list (config, main, dns, NULL,
NULL);
-
- *log_level = g_key_file_get_value (config, logging, level, NULL);
- *log_domains = g_key_file_get_value (config, logging, domains,
NULL);
-
- success = TRUE;
-
-out:
- g_key_file_free (config);
- return success;
-}
-
-static gboolean
parse_state_file (const char *filename,
gboolean *net_enabled,
gboolean *wifi_enabled,
@@ -469,10 +428,9 @@ main (int argc, char *argv[])
GOptionContext *opt_ctx = NULL;
gboolean become_daemon = FALSE;
gboolean g_fatal_warnings = FALSE;
- char *pidfile = NULL, *state_file = NULL, *dhcp = NULL;
- char *config = NULL, *plugins = NULL, *conf_plugins = NULL;
+ char *pidfile = NULL, *state_file = NULL;
+ char *config_path = NULL, *plugins = NULL;
char *log_level = NULL, *log_domains = NULL;
- char **dns = NULL;
gboolean wifi_enabled = TRUE, net_enabled = TRUE, wwan_enabled = TRUE,
wimax_enabled = TRUE;
gboolean success, show_version = FALSE;
NMPolicy *policy = NULL;
@@ -482,9 +440,9 @@ main (int argc, char *argv[])
NMSupplicantManager *sup_mgr = NULL;
NMDHCPManager *dhcp_mgr = NULL;
NMSettings *settings = NULL;
+ NMConfig *config;
GError *error = NULL;
gboolean wrote_pidfile = FALSE;
- char *cfg_log_level = NULL, *cfg_log_domains = NULL;
GOptionEntry options[] = {
{ version, 0, 0, G_OPTION_ARG_NONE, show_version, Print
NetworkManager version and exit, NULL },
@@ -492,7 +450,7 @@ main (int argc, char *argv[])
{ g-fatal-warnings, 0, 0, G_OPTION_ARG_NONE,
g_fatal_warnings, Make all warnings fatal, NULL },
{ pid-file, 0, 0, G_OPTION_ARG_FILENAME, pidfile, Specify
the location of a PID file, filename },
{ state-file, 0, 0, G_OPTION_ARG_FILENAME, state_file,
State file location, /path/to/state.file },
- { config, 0, 0, G_OPTION_ARG_FILENAME, config, Config file
location, /path/to/config.file },
+ { config, 0, 0, G_OPTION_ARG_FILENAME, config_path, Config
file location, /path/to/config.file },
{ plugins, 0, 0, G_OPTION_ARG_STRING, plugins, List of
plugins separated by ',', plugin1,plugin2 },
{ log-level, 0, 0, G_OPTION_ARG_STRING,
[PATCH 3/3] core: split nm_manager_get() to simplify manager creation
OLPC Mesh code now doesn't have to be updated every time we change
the manager's creation arguments. We could make all these arguments
GObject properties of the manager too, but that's more code and
we'd eventually like to figure out a better solution for letting
non-NMManager code listen for device addition/removal.
---
src/main.c|2 +-
src/nm-device-olpc-mesh.c |6 +++---
src/nm-manager.c | 17 -
src/nm-manager.h |5 -
4 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/src/main.c b/src/main.c
index 8d37bc9..59d7cd1 100644
--- a/src/main.c
+++ b/src/main.c
@@ -632,7 +632,7 @@ main (int argc, char *argv[])
goto done;
}
- manager = nm_manager_get (settings,
+ manager = nm_manager_new (settings,
state_file,
net_enabled,
wifi_enabled,
diff --git a/src/nm-device-olpc-mesh.c b/src/nm-device-olpc-mesh.c
index 2f130b1..ddd5198 100644
--- a/src/nm-device-olpc-mesh.c
+++ b/src/nm-device-olpc-mesh.c
@@ -653,7 +653,7 @@ dispose (GObject *object)
device_cleanup (self);
- manager = nm_manager_get (NULL, NULL, FALSE, FALSE, FALSE, FALSE, NULL);
+ manager = nm_manager_get ();
if (priv-device_added_id)
g_signal_handler_disconnect (manager, priv-device_added_id);
g_object_unref (manager);
@@ -852,7 +852,7 @@ is_companion (NMDeviceOlpcMesh *self, NMDevice *other)
priv-companion = other;
/* When we've found the companion, stop listening for other devices */
- manager = nm_manager_get (NULL, NULL, FALSE, FALSE, FALSE, FALSE, NULL);
+ manager = nm_manager_get ();
if (priv-device_added_id) {
g_signal_handler_disconnect (manager, priv-device_added_id);
priv-device_added_id = 0;
@@ -907,7 +907,7 @@ check_companion_cb (gpointer user_data)
if (priv-device_added_id != 0)
return FALSE;
- manager = nm_manager_get (NULL, NULL, FALSE, FALSE, FALSE, FALSE, NULL);
+ manager = nm_manager_get ();
priv-device_added_id = g_signal_connect (manager, device-added,
G_CALLBACK (device_added_cb),
self);
diff --git a/src/nm-manager.c b/src/nm-manager.c
index c74bccb..d347dd0 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -3041,8 +3041,17 @@ out:
return DBUS_HANDLER_RESULT_HANDLED;
}
+static NMManager *singleton = NULL;
+
NMManager *
-nm_manager_get (NMSettings *settings,
+nm_manager_get (void)
+{
+ g_assert (singleton);
+ return g_object_ref (singleton);
+}
+
+NMManager *
+nm_manager_new (NMSettings *settings,
const char *state_file,
gboolean initial_net_enabled,
gboolean initial_wifi_enabled,
@@ -3050,16 +3059,14 @@ nm_manager_get (NMSettings *settings,
gboolean initial_wimax_enabled,
GError **error)
{
- static NMManager *singleton = NULL;
NMManagerPrivate *priv;
DBusGConnection *bus;
DBusConnection *dbus_connection;
- if (singleton)
- return g_object_ref (singleton);
-
g_assert (settings);
+ /* Can only be called once */
+ g_assert (singleton == NULL);
singleton = (NMManager *) g_object_new (NM_TYPE_MANAGER, NULL);
g_assert (singleton);
diff --git a/src/nm-manager.h b/src/nm-manager.h
index afadba2..b044971 100644
--- a/src/nm-manager.h
+++ b/src/nm-manager.h
@@ -67,7 +67,8 @@ typedef struct {
GType nm_manager_get_type (void);
-NMManager *nm_manager_get (NMSettings *settings,
+/* nm_manager_new() should only be used by main.c */
+NMManager *nm_manager_new (NMSettings *settings,
const char *state_file,
gboolean initial_net_enabled,
gboolean initial_wifi_enabled,
@@ -75,6 +76,8 @@ NMManager *nm_manager_get (NMSettings *settings,
gboolean
initial_wimax_enabled,
GError **error);
+NMManager *nm_manager_get (void);
+
void nm_manager_start (NMManager *manager);
/* Device handling */
--
1.7.6.2
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] clean up mobile broadband wizard
On Tue, 2011-09-27 at 16:43 +0100, Bastien Nocera wrote: On Tue, 2011-09-27 at 10:00 -0400, Mathieu Trudel-Lapierre wrote: Hi, I noticed many duplicate buttons and page headers in the mobile broadband wizard, attached is a patch that fixes this. It was a bug in GTK+, which I fixed in time for GNOME 3.2 last week. Was the bug only present in development versions of GTK? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] ModemManager: Clean up GRegex/GMatchInfo leaks
During some other development we found that there was a lot of
inconsistency in freeing GMatchInfo structures after g_regex
operations, and that quite a few match_info structures were probably
being leaked. This patch is the result of a quick audit of the g_regex
callers for properly cleaning up the match_info.
- Nathan
From a090d2f3d99a1bd52fdd652b043e66e7dc48bb2c Mon Sep 17 00:00:00 2001
From: Nathan Williams n...@chromium.org
Date: Mon, 26 Sep 2011 13:20:17 -0400
Subject: [PATCH] Ensure that GMatchInfo and GRegex objects are freed properly.
In particular, g_regex_match() and g_regex_match_full() allocate a
match_info structure on both success and failure, so calling
g_match_info_free() only in the success case is insufficient.
BUG=None
TEST=Inspection
Change-Id: Iea76b5b5dc3ec48120e15601a5e2dd45322133d8
---
plugins/mm-modem-anydata-cdma.c |6 ++
plugins/mm-modem-cinterion-gsm.c |9 +
plugins/mm-modem-huawei-gsm.c|3 ++-
plugins/mm-modem-novatel-gsm.c |3 +--
plugins/mm-modem-samsung-gsm.c |3 ++-
plugins/mm-modem-sierra-gsm.c|4 +++-
plugins/mm-modem-x22x-gsm.c |3 +--
plugins/mm-modem-zte.c |6 +++---
src/mm-generic-gsm.c |4
src/mm-modem-helpers.c | 15 ++-
src/mm-serial-parsers.c | 31 +--
11 files changed, 50 insertions(+), 37 deletions(-)
diff --git a/plugins/mm-modem-anydata-cdma.c b/plugins/mm-modem-anydata-cdma.c
index 7b6b37a..d26d3ec 100644
--- a/plugins/mm-modem-anydata-cdma.c
+++ b/plugins/mm-modem-anydata-cdma.c
@@ -183,6 +183,9 @@ evdo_state_done (MMAtSerialPort *port,
}
}
+g_match_info_free (match_info);
+g_regex_unref (r);
+
done:
mm_generic_cdma_query_reg_state_set_callback_evdo_state (info, reg_state);
mm_callback_info_schedule (info);
@@ -254,6 +257,9 @@ state_done (MMAtSerialPort *port,
}
}
+g_match_info_free (match_info);
+g_regex_unref (r);
+
mm_generic_cdma_query_reg_state_set_callback_1x_state (info, reg_state);
/* Try for EVDO state too */
diff --git a/plugins/mm-modem-cinterion-gsm.c b/plugins/mm-modem-cinterion-gsm.c
index 56a6b00..b6ea841 100644
--- a/plugins/mm-modem-cinterion-gsm.c
+++ b/plugins/mm-modem-cinterion-gsm.c
@@ -615,6 +615,9 @@ get_smong_cb (MMAtSerialPort *port,
priv-sind_psinfo = TRUE;
}
+g_match_info_free (match_info);
+g_regex_unref (regex);
+
mm_callback_info_set_result (info, GUINT_TO_POINTER (act), NULL);
mm_callback_info_schedule (info);
}
@@ -661,9 +664,15 @@ get_sind_cb (MMAtSerialPort *port,
g_free (ind_value);
mm_callback_info_set_result (info, GUINT_TO_POINTER (act), NULL);
mm_callback_info_schedule (info);
+
+g_match_info_free (match_info);
+g_regex_unref (regex);
return;
}
+g_match_info_free (match_info);
+g_regex_unref (regex);
+
/* If there was no 'psinfo' indicator, we'll try AT^SMONG and read the cell
* info table. */
mm_at_serial_port_queue_command (port, ^SMONG, 3, get_smong_cb, info);
diff --git a/plugins/mm-modem-huawei-gsm.c b/plugins/mm-modem-huawei-gsm.c
index e038069..f615e19 100644
--- a/plugins/mm-modem-huawei-gsm.c
+++ b/plugins/mm-modem-huawei-gsm.c
@@ -595,9 +595,10 @@ send_huawei_cpin_done (MMAtSerialPort *port,
mm_callback_info_set_result (info, GUINT_TO_POINTER (attempts_left), NULL);
-g_match_info_free (match_info);
done:
+if (match_info)
+g_match_info_free (match_info);
if (r)
g_regex_unref (r);
mm_serial_port_close (MM_SERIAL_PORT (port));
diff --git a/plugins/mm-modem-novatel-gsm.c b/plugins/mm-modem-novatel-gsm.c
index 5d78db7..706664c 100644
--- a/plugins/mm-modem-novatel-gsm.c
+++ b/plugins/mm-modem-novatel-gsm.c
@@ -198,8 +198,6 @@ parse_nwrat_response (GString *response,
mode = atoi (str);
g_free (str);
-g_match_info_free (match_info);
-
if (mode 0 || mode 2) {
g_set_error_literal (error, MM_MODEM_ERROR, MM_MODEM_ERROR_GENERAL,
Failed to parse mode/tech response);
@@ -219,6 +217,7 @@ parse_nwrat_response (GString *response,
success = TRUE;
out:
+g_match_info_free (match_info);
g_regex_unref (r);
return success;
}
diff --git a/plugins/mm-modem-samsung-gsm.c b/plugins/mm-modem-samsung-gsm.c
index df7a4b4..976d419 100755
--- a/plugins/mm-modem-samsung-gsm.c
+++ b/plugins/mm-modem-samsung-gsm.c
@@ -357,9 +357,10 @@ send_samsung_pinnum_done (MMAtSerialPort *port,
mm_callback_info_set_result (info, GUINT_TO_POINTER (attempts_left), NULL);
-g_match_info_free (match_info);
done:
+if (match_info)
+g_match_info_free (match_info);
if (r)
g_regex_unref (r);
mm_serial_port_close (MM_SERIAL_PORT (port));
diff --git a/plugins/mm-modem-sierra-gsm.c b/plugins/mm-modem-sierra-gsm.c
index 6d4e4d5..c15598f 100644
Re: PATCH] sms_decode_text(): Sanitize 8-bit data so that it is UTF8-clean.
On Mon, 2011-09-26 at 18:29 -0400, Nathan Williams wrote: This keeps ModemManager from crashing deep in the DBus libraries when a SMS Get() or List() DBus operation finds a message that isn't valid UTF-8 and/or has embedded NUL characters. I'll be putting up a separate patch as a proposal for how to avoid this problem in the new API. Sounds fine; though in general we know the encoding that the message comes in with, and we know we need to convert to UTF-8 for D-Bus (and really, everything should be UTF-8 at the boundaries, it would be just horrid to expose any charset encoding details to clients and I don't think we have to). So we should be able to convert to UTF-8 without any real loss of fidelity when reading the message from the modem, and we should be able to convert from UTF-8 to a suitable charset (whatever we've selected from CSCS) when sending messages too. In what cases would we want to send or receive essentially binary data via SMS? AFAIK most of these cases show up as base64 or hex-string SMS if they aren't intended for human consumption. In any case, applied, thanks! Dan - Nathan ___ 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] sms_decode_text(): Sanitize 8-bit data so that it is UTF8-clean.
On Tuesday 27 September 2011, Dan Williams wrote: On Mon, 2011-09-26 at 18:29 -0400, Nathan Williams wrote: This keeps ModemManager from crashing deep in the DBus libraries when a SMS Get() or List() DBus operation finds a message that isn't valid UTF-8 and/or has embedded NUL characters. I'll be putting up a separate patch as a proposal for how to avoid this problem in the new API. Sounds fine; though in general we know the encoding that the message comes in with, and we know we need to convert to UTF-8 for D-Bus (and really, everything should be UTF-8 at the boundaries, it would be just horrid to expose any charset encoding details to clients and I don't think we have to). So we should be able to convert to UTF-8 without any real loss of fidelity when reading the message from the modem, and we should be able to convert from UTF-8 to a suitable charset (whatever we've selected from CSCS) when sending messages too. In what cases would we want to send or receive essentially binary data via SMS? AFAIK most of these cases show up as base64 or hex-string SMS if they aren't intended for human consumption. In any case, applied, thanks! Dan - Nathan ___ 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 Hi Dan, Here's a case you might want to consider. Sometimes mobile networks send WAP pushes to signify that an MMS is ready for retrieval, or send the user revised phone settings etc. Now we can't currently do much with those but they are binary and can contain embedded \x00 which Dbus really won't transfer in a string. But it's no good just ignoring them and not showing the client the message because they take up valuable SIM based SMS slots, if we did then the user would not know of their existence and eventually the SIM would silently fill. I had one WAP push last week that spanned 4 SMS slots. On Wader we worked around this problem by Zipping and Base64 encoding the message before sending over Dbus [0] [1], but I couldn't think of a elegant solution without changing the spec. If you come up with a better solution please let me know and we can revise what we have. [0]:https://forge.betavine.net/plugins/scmsvn/viewcvs.php/trunk/src/core/wader/common/mal.py?root=bcmrev=1210r1=1193r2=1210 [1]:https://forge.betavine.net/plugins/scmsvn/viewcvs.php/trunk/src/core/wader/common/encoding.py?root=bcmrev=1210r1=1194r2=1210 Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH] sms_decode_text(): Sanitize 8-bit data so that it is UTF8-clean.
On Tue, 2011-09-27 at 13:18 -0500, Dan Williams wrote: On Mon, 2011-09-26 at 18:29 -0400, Nathan Williams wrote: This keeps ModemManager from crashing deep in the DBus libraries when a SMS Get() or List() DBus operation finds a message that isn't valid UTF-8 and/or has embedded NUL characters. I'll be putting up a separate patch as a proposal for how to avoid this problem in the new API. Sounds fine; though in general we know the encoding that the message comes in with, and we know we need to convert to UTF-8 for D-Bus (and really, everything should be UTF-8 at the boundaries, it would be just horrid to expose any charset encoding details to clients and I don't think we have to). So we should be able to convert to UTF-8 without any real loss of fidelity when reading the message from the modem, and we should be able to convert from UTF-8 to a suitable charset (whatever we've selected from CSCS) when sending messages too. In what cases would we want to send or receive essentially binary data via SMS? AFAIK most of these cases show up as base64 or hex-string SMS if they aren't intended for human consumption. In any case, applied, thanks! But the patch does appear to break the testcases, could you send along a patch to update those as well? /test_pdu3_8bit: ** ERROR:test-sms.c:231:test_pdu3_8bit: assertion failed (g_value_get_string(value) == (\xe8\x32\x9b\xfd\x46\x97\xd9\xec\x37 \xde)): (\\xe82\\x9b\\xfdF\\x97\\xd9\\xec7\\xde == \3502\233\375F \227\331\3547\336) Thanks, Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] ModemManager: Clean up GRegex/GMatchInfo leaks
On Tue, 2011-09-27 at 12:54 -0400, Nathan Williams wrote: During some other development we found that there was a lot of inconsistency in freeing GMatchInfo structures after g_regex operations, and that quite a few match_info structures were probably being leaked. This patch is the result of a quick audit of the g_regex callers for properly cleaning up the match_info. Applied, thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH] sms_decode_text(): Sanitize 8-bit data so that it is UTF8-clean.
On Tue, Sep 27, 2011 at 2:18 PM, Dan Williams d...@redhat.com wrote: On Mon, 2011-09-26 at 18:29 -0400, Nathan Williams wrote: This keeps ModemManager from crashing deep in the DBus libraries when a SMS Get() or List() DBus operation finds a message that isn't valid UTF-8 and/or has embedded NUL characters. I'll be putting up a separate patch as a proposal for how to avoid this problem in the new API. Sounds fine; though in general we know the encoding that the message comes in with, and we know we need to convert to UTF-8 for D-Bus (and really, everything should be UTF-8 at the boundaries, it would be just horrid to expose any charset encoding details to clients and I don't think we have to). So we should be able to convert to UTF-8 without any real loss of fidelity when reading the message from the modem, and we should be able to convert from UTF-8 to a suitable charset (whatever we've selected from CSCS) when sending messages too. In what cases would we want to send or receive essentially binary data via SMS? AFAIK most of these cases show up as base64 or hex-string SMS if they aren't intended for human consumption. We do do that conversion to UTF-8 when we know the transmission character set, GSM-7 or UCS2. The one fly in this ointment is that one of the possible encodings is, in fact, 8-bit data (TP-DCS value of 04 or f4) with no associated character set. The particular case that brought this to my attention was a test SMS from a carrier that was supposed to contain, I believe, a polyphonic ringtone for some Nokia handset. I'll see about updating the testcases. - Nathan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH] sms_decode_text(): Sanitize 8-bit data so that it is UTF8-clean.
On Tue, 2011-09-27 at 14:55 -0400, Nathan Williams wrote: On Tue, Sep 27, 2011 at 2:18 PM, Dan Williams d...@redhat.com wrote: On Mon, 2011-09-26 at 18:29 -0400, Nathan Williams wrote: This keeps ModemManager from crashing deep in the DBus libraries when a SMS Get() or List() DBus operation finds a message that isn't valid UTF-8 and/or has embedded NUL characters. I'll be putting up a separate patch as a proposal for how to avoid this problem in the new API. Sounds fine; though in general we know the encoding that the message comes in with, and we know we need to convert to UTF-8 for D-Bus (and really, everything should be UTF-8 at the boundaries, it would be just horrid to expose any charset encoding details to clients and I don't think we have to). So we should be able to convert to UTF-8 without any real loss of fidelity when reading the message from the modem, and we should be able to convert from UTF-8 to a suitable charset (whatever we've selected from CSCS) when sending messages too. In what cases would we want to send or receive essentially binary data via SMS? AFAIK most of these cases show up as base64 or hex-string SMS if they aren't intended for human consumption. We do do that conversion to UTF-8 when we know the transmission character set, GSM-7 or UCS2. The one fly in this ointment is that one of the possible encodings is, in fact, 8-bit data (TP-DCS value of 04 or f4) with no associated character set. The particular case that brought this to my attention was a test SMS from a carrier that was supposed to contain, I believe, a polyphonic ringtone for some Nokia handset. Ok, I suppose we could also expose the data as a byte array in the Get() method call along with the 'text' argument. Since it seems like we can probably tell whether it's supposed to be a string or not. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] default VPN import/export path to home directory
On Tue, 2011-09-27 at 10:19 -0400, Mathieu Trudel-Lapierre wrote: Hi, In previous versions of nm-applet on Ubuntu we could notice the default path for import and export of VPN configs being the user's home directory. Looking again, this doesn't appear to be the case in Oneiric, possibly because of changes in GTK. The attached patch defines the current directory as the user's home when the file chooser is being created for import and export. Thanks, applied to 0.8 and 0.9. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
