Re: [MM 0.6] Plumb up the SPN display-rule bits
Hey, This is required for properly displaying local-operator-vs-home-provider information, per 3GPP (31.102 section 4.1.2 on EF_SPN and 22.101 Annex A). For anyone else checking, that's section 4.2.11 in release 11 of the document. Suggestions welcome on the long and somewhat unwieldy property/function names. - Nathan 0001-Retrieve-and-plumb-up-the-SIM-SPN-bits-that-set-oper.patch From 96ce78202344bd928bf602874a087a0adb383cbe Mon Sep 17 00:00:00 2001 From: Nathan Williams n...@chromium.org Date: Wed, 29 Feb 2012 16:25:03 -0500 Subject: [PATCH] Retrieve and plumb up the SIM SPN bits that set operator name display rules. BUG=chromium-os:21522 TEST=Insert SIMs from various operators (T-Mobile, MaxROAM), run mmcli -i 0 Varying conditions include no SPN (ATT), all-FF SPN data (3 Italy), SPN with neither display bit set (3 UK), SPN with a display bit set (MaxROAM) Change-Id: Id83da0e094efe52922dcc21f1420d3f5db5883e3 --- cli/mmcli-sim.c| 14 -- .../org.freedesktop.ModemManager1.Sim.xml | 17 +++ libmm-glib/mm-sim.c| 30 libmm-glib/mm-sim.h|2 + src/mm-sim.c | 49 ++- src/mm-sim.h |2 + 6 files changed, 106 insertions(+), 8 deletions(-) diff --git a/cli/mmcli-sim.c b/cli/mmcli-sim.c index aa39a91..89ceeed 100644 --- a/cli/mmcli-sim.c +++ b/cli/mmcli-sim.c @@ -161,14 +161,18 @@ print_sim_info (MMSim *sim) g_print (SIM '%s'\n, mm_sim_get_path (sim)); g_print ( -\n - Properties | imsi : '%s'\n - |id : '%s'\n - | operator id : '%s'\n - | operator name : '%s'\n, + Properties | imsi : '%s'\n + | id : '%s'\n + | operator id : '%s'\n + |operator name : '%s'\n + |show PLMN at home : %s\n + | show op name roaming : %s\n, VALIDATE (mm_sim_get_imsi (sim)), VALIDATE (mm_sim_get_identifier (sim)), VALIDATE (mm_sim_get_operator_identifier (sim)), - VALIDATE (mm_sim_get_operator_name (sim))); + VALIDATE (mm_sim_get_operator_name (sim)), + mm_sim_get_display_registered_network_name_at_home (sim) ? yes : no, + mm_sim_get_display_operator_name_while_roaming (sim) ? yes : no); } static void diff --git a/introspection/org.freedesktop.ModemManager1.Sim.xml b/introspection/org.freedesktop.ModemManager1.Sim.xml index 14f9077..5833838 100644 --- a/introspection/org.freedesktop.ModemManager1.Sim.xml +++ b/introspection/org.freedesktop.ModemManager1.Sim.xml @@ -99,5 +99,22 @@ -- property name=OperatorName type=s access=read / +!-- + DisplayRegisteredNetworkNameAtHome + + If true, the user interface is required to display the name of + the registered PLMN while registered on a home network (non-roaming). +-- +property name=DisplayRegisteredNetworkNameAtHome type=b access=read / Quoting from the TS: b1=0: display of registered PLMN name not required when registered PLMN is either HPLMN or a PLMN in the service provider PLMN list. b1=1: display of registered PLMN name required when registered PLMN is either HPLMN or a PLMN in the service provider PLMN list. I don't think that DisplayRegisteredNetworkNameAtHome covers everything the property is meant to say. Actually, it hides the main purpose of the property, which is the fact that the registered PLMN name should be displayed even if the network is not the home network, but a network allowed in the PLMN list. E.g. I have a card from the 'Yoigo' operator, and when using 2G my phone connects to the 'Movistar'network: but my phone still needs to display 'Yoigo' instead of 'Movistar'. The fact that the device should display the name of the registered PLMN when in the same home PLMN is quite obvious already. But, I can't think of a better or shorter name... DisplayRegisteredNetworkNameAtHomeOrAllowed is even longer... :-) + +!-- + DisplayOperatorNameWhileRoaming + + If true, the user interface is required to display the operator + name from the SIM (the OperatorName) when registered on a + non-home network (roaming). +-- +property name=DisplayOperatorNameWhileRoaming type=b access=read / + Quoting from the TS: b2=0: display of the service provider name is required when registered PLMN is neither HPLMN nor a PLMN in the service provider PLMN list. b2=1: display of the service provider name is not required when registered PLMN is
Re: NM re-writing /etc/resolv.conf
On 1 Mar 2012, at 12:46, Timothy Murphy wrote: This morning, when I brought my hibernating Fedora-16 laptop to life, I found NM had re-written /etc/resolv.conf , leaving only comments. ... Why does NM do this? As I understand it, /etc/resolv.conf is *supposed* to be re-written to contain the nameservers specified by the DHCP server (see for example man dhclient-script, though note that NetworkManager provides its own script overriding dhclient's default dhclient-script). So, assuming you are using DHCP, perhaps the DHCP query failed. I'll leave the full diagnosis to someone more knowledgeable, but maybe the dhclient or NetworkManager logs will help. Kind regards, David Röthlisberger. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NM re-writing /etc/resolv.conf
On Thu, 2012-03-01 at 12:46 +, Timothy Murphy wrote: This morning, when I brought my hibernating Fedora-16 laptop to life, I found NM had re-written /etc/resolv.conf , leaving only comments. The laptop was connected to the internet before hibernation, and had been working normally. Why does NM do this? Is there any way of stopping it? If NM fails to find connectivity, then any nameservers in /etc/resolv.conf are no longer valid since they cannot be reached. If you have static nameservers that you'd like to use, those should be specified *per-connection*, since as David said, nameservers change depending on where the information came from (VPN, DHCP, PPP, etc). Can you describe your problem in more detail? Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
USB gadget support?
I have F16 here (NM 0.9.2) with a Beagleboard doing USB gadget networking, and NM seems to be treating the wired and USB connections as the same thing. After booting the Beagleboard, I get two Wired items in the NM connection list, but they are sharing a single configuration. This is a problem because I need to share my host's ethernet in order to give the Beagleboard connectivity -- definitely not the same configuration. When I click the + button for a new configuration, my only option is VPN. I'm sure I had this working in F14 or F15, but I can't remember how. Am I missing something simple? Thanks! -- Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] dns: dnsmasq plugin: update command-line parameters for starting dnsmasq
Drop --strict-order; dnsmasq is intelligent enough to ask nameservers in an order that makes the best of possibly slow nameservers (or broken ones), and interrogating them in strict order breaks this. Add --no-hosts: by default dnsmasq will read /etc/hosts as a list of things to resolve statically; this is something we want to avoid as nsswitch.conf already lists files as the first data store to look at; where the entries in /etc/hosts will already have been returned if that's what the user wants to see. If the /etc/hosts file then changes, dnsmasq would have to be restarted before the user would get the new value resolved externally. Avoid this, let /etc/hosts override DNS entries normally through the resolver and show changes as soon as the file is updated. --- src/dns-manager/nm-dns-dnsmasq.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/dns-manager/nm-dns-dnsmasq.c b/src/dns-manager/nm-dns-dnsmasq.c index e44513b..6314438 100644 --- a/src/dns-manager/nm-dns-dnsmasq.c +++ b/src/dns-manager/nm-dns-dnsmasq.c @@ -302,7 +302,7 @@ update (NMDnsPlugin *plugin, argv[0] = find_dnsmasq (); argv[1] = --no-resolv; /* Use only commandline */ argv[2] = --keep-in-foreground; - argv[3] = --strict-order; + argv[3] = --no-hosts; /* don't use /etc/hosts to resolve */ argv[4] = --bind-interfaces; argv[5] = --pid-file= PIDFILE; argv[6] = --listen-address=127.0.0.1; /* Should work for both 4 and 6 */ -- 1.7.9 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] nm-manager.c:474:20: error: unused variable ‘priv’
On Wed, 2012-02-29 at 15:04 +0100, Jiri Popelka wrote:
---
src/nm-manager.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Applied, thanks.
Dan
diff --git a/src/nm-manager.c b/src/nm-manager.c
index 146d491..d04a4e4 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -471,7 +471,9 @@ manager_device_state_changed (NMDevice *device,
gpointer user_data)
{
NMManager *self = NM_MANAGER (user_data);
+#if WITH_CONCHECK
NMManagerPrivate *priv = NM_MANAGER_GET_PRIVATE (self);
+#endif
switch (new_state) {
case NM_DEVICE_STATE_UNMANAGED:
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
+ property name=DisplayRegisteredNetworkNameAtHome type=b access=read / Quoting from the TS: b1=0: display of registered PLMN name not required when registered PLMN is either HPLMN or a PLMN in the service provider PLMN list. b1=1: display of registered PLMN name required when registered PLMN is either HPLMN or a PLMN in the service provider PLMN list. I don't think that DisplayRegisteredNetworkNameAtHome covers everything the property is meant to say. Actually, it hides the main purpose of the property, which is the fact that the registered PLMN name should be displayed even if the network is not the home network, but a network allowed in the PLMN list. E.g. I have a card from the 'Yoigo' operator, and when using 2G my phone connects to the 'Movistar'network: but my phone still needs to display 'Yoigo' instead of 'Movistar'. The fact that the device should display the name of the registered PLMN when in the same home PLMN is quite obvious already. ... The name DisplayOperatorNameWhileRoaming is also not fully clear. 'Roaming' means for the modem/phone 'not in the home network', and that covers both being in a network allowed in the list stored in the SIM card, or really roaming in another not-listed network. Following my example before, when I connect to the Movistar network with a Yoigo SIM card, I will be reported as being roaming, even if the network is one of the allowed networks in the list stored in the SIM card. I don't think this is right - the service provider PLMN list, EF_SPDI, referred to in 31.102 is not the list of all possible networks to roam on; it's a separate list that exists purely for fine-tuning this display. If the card from 'Yoigo' doesn't list 'Movistar', then bit 1 is irrelevant, we always display 'Movistar', and bit 2 controls whether we display 'Yoigo' as well. (If the card from 'Yoigo' did list the 'Movistar' PLMN on its (E)HPLMN list, or has it in the EF_SPDI list, then bit 1 controls whether we need to mention 'Movistar' at all (we always need to mention 'Yoigo' when on a home network)). I admit that the inclusion of the EF_SPDI list in the discussion makes the home/roaming distinction a bit fuzzier (though I have yet to see a non-empty EF_SPDI list), but I think that's roughly the right division. From Annex A.4 of 22.101: When registered on the HPLMN, or one of the PLMN Identifications used for Service Provider Name display: (i) The SP Name shall be displayed; (ii) Display of the PLMN Name is an operators option by setting the appropriate fields in the USIM (i.e. the Service Provider name shall be displayed either in parallel to the PLMN Name or instead of the PLMN Name). When registered on neither the HPLMN, nor one of the PLMN Identifications used for Service Provider Name display: (i) The PLMN name shall be displayed; (ii) Display of the SP Name is an operators option by setting the appropriate fields in the USIM. - Nathan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: USB gadget support?
On Tue, 2012-02-28 at 17:58 -0800, Hollis Blanchard wrote: I have F16 here (NM 0.9.2) with a Beagleboard doing USB gadget networking, and NM seems to be treating the wired and USB connections as the same thing. After booting the Beagleboard, I get two Wired items in the NM connection list, but they are sharing a single configuration. This is a problem because I need to share my host's ethernet in order to give the Beagleboard connectivity -- definitely not the same configuration. When I click the + button for a new configuration, my only option is VPN. I'm sure I had this working in F14 or F15, but I can't remember how. Am I missing something simple? Thanks! Hi Hollis! Do either of the interfaces have stable MAC addresses? The usual mechanism would be to lock connections to each of the MAC addresses of the interfaces, so that you have connection #1 locked to onboard wired, and connection #2 locked to USB, and then they are both set up correctly. Unfortunately, I think on the gadget stuff sometimes the MAC address is random and then this becomes an excercise in creating udev rules to set the MAC address to a well-known one. Unfortunately, as I'm sure you know, device names are not stable; they depend on bus topology and even module loading order. I recently had a bug where a module switched it's firmware loading scheme, delaying the call to register_netdev() for a second or two, which caused another network device to register itself first. Fun times... thus NM doesn't allow locking connections to interface names. (another aside: that would have completely broken networking in the switch from F15 - F16 where interface names are now created depending on the bus, slot, and BIOS information). Anyway, if you can get stable MAC addresses, then lock the connections in nm-connection-editor to the MAC address of the interface and it should work exactly as you expect. Let me know how it goes. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 2/2] firewall-manager: changing the zone an interface belongs to
When we want to change the zone an interface belongs to
we can't use firewalld's addInterface() because this one
doesn't allow to add interface to zone when it already
has been part of some other/same zone.
We need to use changeZone() method instead - hopefuly
this is the final name of this method.
---
src/firewall-manager/nm-firewall-manager.c | 25 ++--
src/firewall-manager/nm-firewall-manager.h | 13 +-
src/nm-device.c|3 +-
src/nm-policy.c| 34 +++
4 files changed, 41 insertions(+), 34 deletions(-)
diff --git a/src/firewall-manager/nm-firewall-manager.c
b/src/firewall-manager/nm-firewall-manager.c
index d9122af..303c8cd 100644
--- a/src/firewall-manager/nm-firewall-manager.c
+++ b/src/firewall-manager/nm-firewall-manager.c
@@ -73,7 +73,7 @@ cb_info_free (CBInfo *info)
}
static void
-add_cb (DBusGProxy *proxy, DBusGProxyCall *call_id, gpointer user_data)
+add_or_change_cb (DBusGProxy *proxy, DBusGProxyCall *call_id, gpointer
user_data)
{
CBInfo *info = user_data;
GError *error = NULL;
@@ -83,7 +83,7 @@ add_cb (DBusGProxy *proxy, DBusGProxyCall *call_id, gpointer
user_data)
G_TYPE_STRING, zone,
G_TYPE_INVALID)) {
g_assert (error);
- nm_log_warn (LOGD_FIREWALL, (%s) firewall zone add failed:
(%d) %s,
+ nm_log_warn (LOGD_FIREWALL, (%s) firewall zone add/change
failed: (%d) %s,
info-iface, error-code, error-message);
}
@@ -94,18 +94,19 @@ add_cb (DBusGProxy *proxy, DBusGProxyCall *call_id,
gpointer user_data)
}
gpointer
-nm_firewall_manager_add_to_zone (NMFirewallManager *self,
- const char *iface,
- const char *zone,
- FwAddToZoneFunc callback,
- gpointer user_data1,
- gpointer user_data2)
+nm_firewall_manager_add_or_change_zone (NMFirewallManager *self,
+const char *iface,
+const char *zone,
+gboolean add, /* TRUE == add, FALSE ==
change */
+FwAddToZoneFunc callback,
+gpointer user_data1,
+gpointer user_data2)
{
NMFirewallManagerPrivate *priv = NM_FIREWALL_MANAGER_GET_PRIVATE (self);
CBInfo *info;
if (priv-running == FALSE) {
- nm_log_dbg (LOGD_FIREWALL, (%s) firewall zone add skipped (not
running), iface);
+ nm_log_dbg (LOGD_FIREWALL, (%s) firewall zone add/change
skipped (not running), iface);
callback (NULL, user_data1, user_data2);
return NULL;
}
@@ -116,10 +117,10 @@ nm_firewall_manager_add_to_zone (NMFirewallManager *self,
info-user_data1 = user_data1;
info-user_data2 = user_data2;
- nm_log_dbg (LOGD_FIREWALL, (%s) firewall zone add - %s, iface, zone
);
+ nm_log_dbg (LOGD_FIREWALL, (%s) firewall zone %s - %s, iface, add ?
add : change, zone);
return dbus_g_proxy_begin_call_with_timeout (priv-proxy,
-addInterface,
-add_cb,
+add ? addInterface :
changeZone,
+add_or_change_cb,
info,
(GDestroyNotify)
cb_info_free,
1, /* timeout */
diff --git a/src/firewall-manager/nm-firewall-manager.h
b/src/firewall-manager/nm-firewall-manager.h
index ffc6a30..113b78e 100644
--- a/src/firewall-manager/nm-firewall-manager.h
+++ b/src/firewall-manager/nm-firewall-manager.h
@@ -60,12 +60,13 @@ typedef void (*FwAddToZoneFunc) (GError *error,
gpointer user_data1,
gpointer user_data2);
-gpointer nm_firewall_manager_add_to_zone (NMFirewallManager *mgr,
- const char *iface,
- const char *zone,
- FwAddToZoneFunc callback,
- gpointer user_data1,
- gpointer user_data2);
+gpointer nm_firewall_manager_add_or_change_zone (NMFirewallManager *mgr,
+ const char *iface,
+ const char *zone,
+ gboolean add,
+
Re: USB gadget support?
On 03/01/2012 09:47 AM, Dan Williams wrote: On Tue, 2012-02-28 at 17:58 -0800, Hollis Blanchard wrote: I have F16 here (NM 0.9.2) with a Beagleboard doing USB gadget networking, and NM seems to be treating the wired and USB connections as the same thing. After booting the Beagleboard, I get two Wired items in the NM connection list, but they are sharing a single configuration. This is a problem because I need to share my host's ethernet in order to give the Beagleboard connectivity -- definitely not the same configuration. When I click the + button for a new configuration, my only option is VPN. I'm sure I had this working in F14 or F15, but I can't remember how. Am I missing something simple? Thanks! [...] Anyway, if you can get stable MAC addresses, then lock the connections in nm-connection-editor to the MAC address of the interface and it should work exactly as you expect. Let me know how it goes. Ah ha... nm-connection-editor is the app I remember. I guess the NM applet in Gnome 3 has regressed from Gnome 2, and that's the only way I knew to configure this stuff. Thanks for the hint; I should be good now. :) Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/2] firewall-manager: add interfaces to zones after firewall (re)start
Because firewalld has no idea what interface is part of which zone
we need to inform it after it (re)starts what interface belongs to which
zone.
---
src/firewall-manager/nm-firewall-manager.c | 19 +
src/firewall-manager/nm-firewall-manager.h |3 ++
src/nm-policy.c| 31
3 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/src/firewall-manager/nm-firewall-manager.c
b/src/firewall-manager/nm-firewall-manager.c
index b2fd1ce..d9122af 100644
--- a/src/firewall-manager/nm-firewall-manager.c
+++ b/src/firewall-manager/nm-firewall-manager.c
@@ -47,6 +47,14 @@ typedef struct {
gbooleandisposed;
} NMFirewallManagerPrivate;
+enum {
+ STARTED,
+
+ LAST_SIGNAL
+};
+
+static guint signals[LAST_SIGNAL] = { 0 };
+
//
typedef struct {
@@ -204,6 +212,7 @@ name_owner_changed (NMDBusManager *dbus_mgr,
if (!old_owner_good new_owner_good) {
nm_log_dbg (LOGD_FIREWALL, firewall started);
set_running (self, TRUE);
+ g_signal_emit (self, signals[STARTED], 0);
} else if (old_owner_good !new_owner_good) {
nm_log_dbg (LOGD_FIREWALL, firewall stopped);
set_running (self, FALSE);
@@ -306,5 +315,15 @@ nm_firewall_manager_class_init (NMFirewallManagerClass
*klass)
Available,
FALSE,
G_PARAM_READABLE));
+
+ signals[STARTED] =
+ g_signal_new (started,
+ G_OBJECT_CLASS_TYPE (object_class),
+ G_SIGNAL_RUN_FIRST,
+ G_STRUCT_OFFSET
(NMFirewallManagerClass, started),
+ NULL, NULL,
+ g_cclosure_marshal_VOID__VOID,
+ G_TYPE_NONE, 0);
+
}
diff --git a/src/firewall-manager/nm-firewall-manager.h
b/src/firewall-manager/nm-firewall-manager.h
index b6d6da7..ffc6a30 100644
--- a/src/firewall-manager/nm-firewall-manager.h
+++ b/src/firewall-manager/nm-firewall-manager.h
@@ -47,6 +47,9 @@ typedef struct {
typedef struct {
GObjectClass parent;
+
+ /* Signals */
+ void (*started) (NMFirewallManager *manager);
} NMFirewallManagerClass;
GType nm_firewall_manager_get_type (void);
diff --git a/src/nm-policy.c b/src/nm-policy.c
index 12bb43a..c13506e 100644
--- a/src/nm-policy.c
+++ b/src/nm-policy.c
@@ -55,6 +55,7 @@ struct NMPolicy {
gulong vpn_deactivated_id;
NMFirewallManager *fw_manager;
+ gulong fw_started_id;
NMSettings *settings;
@@ -1326,6 +1327,32 @@ inform_firewall_about_zone (NMPolicy *policy,
NMConnection *connection)
}
static void
+firewall_started (NMFirewallManager *manager,
+ gpointer user_data)
+{
+ NMPolicy *policy = (NMPolicy *) user_data;
+ NMConnection *connection;
+ NMSettingConnection *s_con;
+ GSList *iter, *devices;
+
+ devices = nm_manager_get_devices (policy-manager);
+ for (iter = devices; iter; iter = g_slist_next (iter)) {
+ NMDevice *dev = NM_DEVICE (iter-data);
+
+ connection = get_device_connection (dev);
+ s_con = nm_connection_get_setting_connection (connection);
+ if (nm_device_get_state (dev) == NM_DEVICE_STATE_ACTIVATED) {
+ nm_firewall_manager_add_to_zone (policy-fw_manager,
+nm_device_get_ip_iface
(dev),
+
nm_setting_connection_get_zone (s_con),
+add_to_zone_cb,
+g_object_ref (dev),
+NULL);
+ }
+ }
+}
+
+static void
connection_updated (NMSettings *settings,
NMConnection *connection,
gpointer user_data)
@@ -1456,6 +1483,9 @@ nm_policy_new (NMManager *manager,
policy-vpn_deactivated_id = id;
policy-fw_manager = nm_firewall_manager_get();
+ id = g_signal_connect (policy-fw_manager, started,
+ G_CALLBACK (firewall_started), policy);
+ policy-fw_started_id = id;
_connect_manager_signal (policy, state-changed, global_state_changed);
_connect_manager_signal (policy, notify:: NM_MANAGER_HOSTNAME,
hostname_changed);
@@ -1501,6 +1531,7 @@ nm_policy_destroy (NMPolicy *policy)
g_signal_handler_disconnect (policy-vpn_manager,
policy-vpn_deactivated_id);
g_object_unref (policy-vpn_manager);
+ g_signal_handler_disconnect (policy-fw_manager,
Re: USB gadget support?
Hi Dan, I have F16 here (NM 0.9.2) with a Beagleboard doing USB gadget networking, and NM seems to be treating the wired and USB connections as the same thing. After booting the Beagleboard, I get two Wired items in the NM connection list, but they are sharing a single configuration. This is a problem because I need to share my host's ethernet in order to give the Beagleboard connectivity -- definitely not the same configuration. When I click the + button for a new configuration, my only option is VPN. I'm sure I had this working in F14 or F15, but I can't remember how. Am I missing something simple? Thanks! Do either of the interfaces have stable MAC addresses? The usual mechanism would be to lock connections to each of the MAC addresses of the interfaces, so that you have connection #1 locked to onboard wired, and connection #2 locked to USB, and then they are both set up correctly. Unfortunately, I think on the gadget stuff sometimes the MAC address is random and then this becomes an excercise in creating udev rules to set the MAC address to a well-known one. I fixed this in the kernel a long time ago. USB networking gadgets contain DEVTYPE=gadget. No need to play crazy address tricks. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM 0.6] Plumb up the SPN display-rule bits
On Thu, 2012-03-01 at 14:28 +0100, Aleksander Morgado wrote: Hey, This is required for properly displaying local-operator-vs-home-provider information, per 3GPP (31.102 section 4.1.2 on EF_SPN and 22.101 Annex A). For anyone else checking, that's section 4.2.11 in release 11 of the document. Suggestions welcome on the long and somewhat unwieldy property/function names. - Nathan 0001-Retrieve-and-plumb-up-the-SIM-SPN-bits-that-set-oper.patch From 96ce78202344bd928bf602874a087a0adb383cbe Mon Sep 17 00:00:00 2001 From: Nathan Williams n...@chromium.org Date: Wed, 29 Feb 2012 16:25:03 -0500 Subject: [PATCH] Retrieve and plumb up the SIM SPN bits that set operator name display rules. BUG=chromium-os:21522 TEST=Insert SIMs from various operators (T-Mobile, MaxROAM), run mmcli -i 0 Varying conditions include no SPN (ATT), all-FF SPN data (3 Italy), SPN with neither display bit set (3 UK), SPN with a display bit set (MaxROAM) Change-Id: Id83da0e094efe52922dcc21f1420d3f5db5883e3 --- cli/mmcli-sim.c| 14 -- .../org.freedesktop.ModemManager1.Sim.xml | 17 +++ libmm-glib/mm-sim.c| 30 libmm-glib/mm-sim.h|2 + src/mm-sim.c | 49 ++- src/mm-sim.h |2 + 6 files changed, 106 insertions(+), 8 deletions(-) diff --git a/cli/mmcli-sim.c b/cli/mmcli-sim.c index aa39a91..89ceeed 100644 --- a/cli/mmcli-sim.c +++ b/cli/mmcli-sim.c @@ -161,14 +161,18 @@ print_sim_info (MMSim *sim) g_print (SIM '%s'\n, mm_sim_get_path (sim)); g_print ( -\n - Properties | imsi : '%s'\n - |id : '%s'\n - | operator id : '%s'\n - | operator name : '%s'\n, + Properties | imsi : '%s'\n + | id : '%s'\n + | operator id : '%s'\n + |operator name : '%s'\n + |show PLMN at home : %s\n + | show op name roaming : %s\n, VALIDATE (mm_sim_get_imsi (sim)), VALIDATE (mm_sim_get_identifier (sim)), VALIDATE (mm_sim_get_operator_identifier (sim)), - VALIDATE (mm_sim_get_operator_name (sim))); + VALIDATE (mm_sim_get_operator_name (sim)), + mm_sim_get_display_registered_network_name_at_home (sim) ? yes : no, + mm_sim_get_display_operator_name_while_roaming (sim) ? yes : no); } static void diff --git a/introspection/org.freedesktop.ModemManager1.Sim.xml b/introspection/org.freedesktop.ModemManager1.Sim.xml index 14f9077..5833838 100644 --- a/introspection/org.freedesktop.ModemManager1.Sim.xml +++ b/introspection/org.freedesktop.ModemManager1.Sim.xml @@ -99,5 +99,22 @@ -- property name=OperatorName type=s access=read / +!-- + DisplayRegisteredNetworkNameAtHome + + If true, the user interface is required to display the name of + the registered PLMN while registered on a home network (non-roaming). +-- +property name=DisplayRegisteredNetworkNameAtHome type=b access=read / Quoting from the TS: b1=0: display of registered PLMN name not required when registered PLMN is either HPLMN or a PLMN in the service provider PLMN list. b1=1: display of registered PLMN name required when registered PLMN is either HPLMN or a PLMN in the service provider PLMN list. So let me think this through... bit 1 is about what to display when the registered network is a well-known network, ie a PLMN known to the SIM. 0 means that the phone does not need to show the registered network name if it's well-known network. They probably should have just said 0 means the opposite of 1, the terminology here is kinda confusing. 1 means that the registered network name is required to be shown if the network is a well-known network. I guess b1=1 would force showing a roaming partner's name instead of the SPN if the roaming partner is known to the SIM? I don't think that DisplayRegisteredNetworkNameAtHome covers everything the property is meant to say. Actually, it hides the main purpose of the property, which is the fact that the registered PLMN name should be displayed even if the network is not the home network, but a network allowed in the PLMN list. E.g. I have a card from the 'Yoigo' operator, and when using 2G my phone connects to the 'Movistar'network: but my phone still needs to display 'Yoigo' instead of 'Movistar'. The fact that the device should display the name of
Re: [MM 0.6] Plumb up the SPN display-rule bits
Hey Dan Nathan,
If we did combine both bits into one property, then we'd get the
following logic:
enum {
DISPLAY_UNRESTRICTED = 0,
DISPLAY_REGISTERED = 1,
DISPLAY_SPN = 2
} DisplayName;
display = DISPLAY_UNRESTRICTED
if (registered network is well-known) {
if (b1 == 1)
display = DISPLAY_REGISTERED
} else {
if (b2 == 0)
display = DISPLAY_SPN
}
This logic gets aligned more or less with some piece of code I found
from Android sources:
/**
* Returns the SpnDisplayRule based on settings on the SIM and the
* specified plmn (currently-registered PLMN). See TS 22.101 AnnexA
* and TS 51.011 10.3.11 for details.
*
* If the SPN is not found on the SIM, the rule is always PLMN_ONLY.
*/
protected int getDisplayRule(String plmn) {
int rule;
if (spn == null || spnDisplayCondition == -1) {
// EF_SPN was not found on the SIM, or not yet loaded. Just show ONS.
rule = SPN_RULE_SHOW_PLMN;
} else if (isOnMatchingPlmn(plmn)) {
// (Checks if plmn is HPLMN or on the spdiNetworks list.)
rule = SPN_RULE_SHOW_SPN;
if ((spnDisplayCondition 0x01) == 0x01)
// ONS required when registered to HPLMN or PLMN in EF_SPDI
rule |= SPN_RULE_SHOW_PLMN;
}
} else {
rule = SPN_RULE_SHOW_PLMN;
if ((spnDisplayCondition 0x02) == 0x00) {
// SPN required if not registered to HPLMN or PLMN in EF_SPDI
rule |= SPN_RULE_SHOW_SPN;
}
}
return rule;
}
Regardless of the meaning of the SPDI Networks list, it's probably a
good approach to follow. Nathan, what do you think?
Also, if we do expose these two properties we also need to load and
expose the SPDI network list, or the properties will be useless.
--
Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Modemmanager - how to send sms? - receiving is ok
On Thu, 2012-02-23 at 16:33 +0100, PongráczI wrote: eredeti üzenet- Feladó: Marcel Holtmann mar...@holtmann.org Címzett: Dan Williams d...@redhat.com CC: PongráczI , networkmanager-list@gnome.org Dátum: Thu, 16 Feb 2012 18:21:59 +0100 - Is that possible to fix this issue into MM_05 and/or master branch? Yeah, I thought the issue was that it doesn't like text mode, while gammu uses PDU mode, and we were going to fix MM to fall back to PDU mode if it was supported and text mode failed. But that fix isn't quite in yet. a serious piece of advise, go for PDU by default and only fall back to text mode if you can't do PDU. Text mode on almost every modern modem is horrible broken. Hello Guys, I would like to ask do you have a schedule, when will you patch the master or MM_05 branch with this PDU sending modification? I've just pushed a fix to git master and MM_05 that should deal with the issue, can you test for me? Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: USB gadget support?
On Thu, 2012-03-01 at 11:21 -0800, Marcel Holtmann wrote: Hi Dan, I have F16 here (NM 0.9.2) with a Beagleboard doing USB gadget networking, and NM seems to be treating the wired and USB connections as the same thing. After booting the Beagleboard, I get two Wired items in the NM connection list, but they are sharing a single configuration. This is a problem because I need to share my host's ethernet in order to give the Beagleboard connectivity -- definitely not the same configuration. When I click the + button for a new configuration, my only option is VPN. I'm sure I had this working in F14 or F15, but I can't remember how. Am I missing something simple? Thanks! Do either of the interfaces have stable MAC addresses? The usual mechanism would be to lock connections to each of the MAC addresses of the interfaces, so that you have connection #1 locked to onboard wired, and connection #2 locked to USB, and then they are both set up correctly. Unfortunately, I think on the gadget stuff sometimes the MAC address is random and then this becomes an excercise in creating udev rules to set the MAC address to a well-known one. I fixed this in the kernel a long time ago. USB networking gadgets contain DEVTYPE=gadget. No need to play crazy address tricks. Even if they have DEVTYPE=gadget, if you have two gadget devices, you still need some way to associate configuration with a particular gadget netdev. Which comes back to MAC address, really... Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCHv2] bonding: Writer support
On Fri, 2012-02-24 at 15:31 +0100, Thomas Graf wrote:
For bonding-master:
TYPE=bond
BONDING_MASTER=yes
DEVICE=NAME
BONDING_OPTS=...
For bonding-slaves:
MASTER=NAME
v2: Resolved test failures after feedback from Jirka.
Pushed, thanks.
Dan
Signed-off-by: Thomas Graf tg...@redhat.com
---
.../plugins/ifcfg-rh/tests/test-ifcfg-rh.c | 280
+++-
src/settings/plugins/ifcfg-rh/writer.c | 61 +
2 files changed, 339 insertions(+), 2 deletions(-)
diff --git a/src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c
b/src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c
index 348e192..c385702 100644
--- a/src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c
+++ b/src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c
@@ -11914,6 +11914,145 @@ test_read_bond_main (void)
g_object_unref (connection);
}
+static void
+test_write_bond_main (void)
+{
+ NMConnection *connection;
+ NMConnection *reread;
+ NMSettingConnection *s_con;
+ NMSettingBond *s_bond;
+ NMSettingIP4Config *s_ip4;
+ NMSettingIP6Config *s_ip6;
+ NMSettingWired *s_wired;
+ char *uuid;
+ const guint32 ip1 = htonl (0x01010103);
+ const guint32 gw = htonl (0x01010101);
+ const guint32 prefix = 24;
+ NMIP4Address *addr;
+ gboolean success;
+ GError *error = NULL;
+ char *testfile = NULL;
+ char *unmanaged = NULL;
+ char *keyfile = NULL;
+ char *routefile = NULL;
+ char *route6file = NULL;
+ gboolean ignore_error = FALSE;
+
+ connection = nm_connection_new ();
+ ASSERT (connection != NULL,
+ bond-main-write, failed to allocate new connection);
+
+ /* Connection setting */
+ s_con = (NMSettingConnection *) nm_setting_connection_new ();
+ ASSERT (s_con != NULL,
+ bond-main-write, failed to allocate new %s setting,
+ NM_SETTING_CONNECTION_SETTING_NAME);
+ nm_connection_add_setting (connection, NM_SETTING (s_con));
+
+ uuid = nm_utils_uuid_generate ();
+ g_object_set (s_con,
+ NM_SETTING_CONNECTION_ID, Test Write Bond Main,
+ NM_SETTING_CONNECTION_UUID, uuid,
+ NM_SETTING_CONNECTION_AUTOCONNECT, TRUE,
+ NM_SETTING_CONNECTION_TYPE, NM_SETTING_BOND_SETTING_NAME,
+ NULL);
+ g_free (uuid);
+
+ /* Wired setting */
+ s_wired = (NMSettingWired *) nm_setting_wired_new ();
+ ASSERT (s_wired != NULL,
+ bond-main-write, failed to allocate new %s setting,
+ NM_SETTING_WIRED_SETTING_NAME);
+ nm_connection_add_setting (connection, NM_SETTING (s_wired));
+
+ /* bond setting */
+ s_bond = (NMSettingBond *) nm_setting_bond_new ();
+ ASSERT (s_bond != NULL,
+ bond-main-write, failed to allocate new %s setting,
+ NM_SETTING_BOND_SETTING_NAME);
+ nm_connection_add_setting (connection, NM_SETTING (s_bond));
+
+ g_object_set (s_bond,
+ NM_SETTING_BOND_INTERFACE_NAME, bond0,
+ NULL);
+
+ /* IP4 setting */
+ s_ip4 = (NMSettingIP4Config *) nm_setting_ip4_config_new ();
+ ASSERT (s_ip4 != NULL,
+ bond-main-write, failed to allocate new %s setting,
+ NM_SETTING_IP4_CONFIG_SETTING_NAME);
+ nm_connection_add_setting (connection, NM_SETTING (s_ip4));
+
+ g_object_set (s_ip4,
+ NM_SETTING_IP4_CONFIG_METHOD,
NM_SETTING_IP4_CONFIG_METHOD_MANUAL,
+ NM_SETTING_IP4_CONFIG_MAY_FAIL, TRUE,
+ NULL);
+
+ addr = nm_ip4_address_new ();
+ nm_ip4_address_set_address (addr, ip1);
+ nm_ip4_address_set_prefix (addr, prefix);
+ nm_ip4_address_set_gateway (addr, gw);
+ nm_setting_ip4_config_add_address (s_ip4, addr);
+ nm_ip4_address_unref (addr);
+
+ /* IP6 setting */
+ s_ip6 = (NMSettingIP6Config *) nm_setting_ip6_config_new ();
+ ASSERT (s_ip6 != NULL,
+ bond-main-write, failed to allocate new %s setting,
+ NM_SETTING_IP6_CONFIG_SETTING_NAME);
+ nm_connection_add_setting (connection, NM_SETTING (s_ip6));
+
+ g_object_set (s_ip6,
+ NM_SETTING_IP6_CONFIG_METHOD,
NM_SETTING_IP6_CONFIG_METHOD_IGNORE,
+ NULL);
+
+ ASSERT (nm_connection_verify (connection, error) == TRUE,
+ bond-main-write, failed to verify connection: %s,
+ (error error-message) ? error-message : (unknown));
+
+ /* Save the ifcfg */
+ success = writer_new_connection (connection,
+ TEST_SCRATCH_DIR /network-scripts/,
+ testfile,
+ error);
+ ASSERT (success == TRUE,
+ bond-main-write, failed to write connection to disk: %s,
+
ANN: ModemManager 0.5.1.97 (0.5.2-rc1)
Hi, Now available to download: http://ftp.gnome.org/pub/GNOME/sources/ModemManager/0.5/ModemManager-0.5.1.97.tar.xz and has the following changes from ModemManager 0.5.0: - Better detection of registration state when connecting - Added support for more Ericsson modems - Many memory leak fixes - Ensure Gobi devices are driven by the gobi plugin - Added multi-part SMS message support - Better handling of requests when modem is disabled - USSD fixes for Huawei devices - Added support for Nokia Internet Sticks - Fixed quirky response handling on some Cinterion modems - Fixed CREG response handling on modems that include the RAC - Skip sending power-up command if modem is already powered up - Added support for Sierra Wireless devices using Icera chips (USB305, Lightning) - Fixed sending SMS messages with modems that only support PDU mode - Fix reading SMS messages in text mode - Fix communication with some Nokia phones Testing appreciated! I plan to release MM 0.5.2 next week. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: USB gadget support?
Hi Dan, I have F16 here (NM 0.9.2) with a Beagleboard doing USB gadget networking, and NM seems to be treating the wired and USB connections as the same thing. After booting the Beagleboard, I get two Wired items in the NM connection list, but they are sharing a single configuration. This is a problem because I need to share my host's ethernet in order to give the Beagleboard connectivity -- definitely not the same configuration. When I click the + button for a new configuration, my only option is VPN. I'm sure I had this working in F14 or F15, but I can't remember how. Am I missing something simple? Thanks! Do either of the interfaces have stable MAC addresses? The usual mechanism would be to lock connections to each of the MAC addresses of the interfaces, so that you have connection #1 locked to onboard wired, and connection #2 locked to USB, and then they are both set up correctly. Unfortunately, I think on the gadget stuff sometimes the MAC address is random and then this becomes an excercise in creating udev rules to set the MAC address to a well-known one. I fixed this in the kernel a long time ago. USB networking gadgets contain DEVTYPE=gadget. No need to play crazy address tricks. Even if they have DEVTYPE=gadget, if you have two gadget devices, you still need some way to associate configuration with a particular gadget netdev. Which comes back to MAC address, really... how do you run two gadgets (device side) anyway. The current gadget subsystem is limiting here. Also what you wanna do is run a DHCP server on this gadget. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Modemmanager - how to send sms? - receiving is ok
Hello Guys, I would like to ask do you have a schedule, when will you patch the master or MM_05 branch with this PDU sending modification? I've just pushed a fix to git master and MM_05 that should deal with the issue, can you test for me? Thanks! Dan Hello Dan, Thank you very much, of course I will test it and report the result today. István ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Wired and Wireless Devices not being detected
Hi all.
I have written a very basic python program, that utilizes Networkmanager
dbu-apis, to detect addition/removal of network devices.
It's working as expected, when I insert a 3G USB modem (both addition and
removal callbacks are hit as expected).
However, when I try this with
a. Inserting/Removing a wired network jack
b. Enable/Disable Wireless from the Dell Keyboard
c. On/Off the wireless modem-cum-router-cum-accesspoint
neither of the callbacks is hit.
Following is the program (in whole; can be cut and paste)::
=
This program notifies the addition and removal of a network device.
Device types tested ::
a. 3G Modem (Idea 3G HSPDA Net Setter)
Done via plugging/unplugging the USB.
:( :( :(
I have not been able to test add/removal of wifi-device, or even a
wired device.
import dbus
from dbus.mainloop.glib import DBusGMainLoop
DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus()
The names have been designed, keeping in consistency of the
nomenclature used in add_signal_receiver method.
NM_BUS_NAME= 'org.freedesktop.NetworkManager'
NM_PATH= '/org/freedesktop/NetworkManager'
NM_DBUS_INTERFACE = 'org.freedesktop.NetworkManager'
Note that the following is not specifically tied to Network Manager.
DBUS_PROPS_DBUS_INTERFACE = 'org.freedesktop.DBus.Properties'
Some more :)
NM_DEVICE_DBUS_INTERFACE = 'org.freedesktop.NetworkManager.Device'
NM_WIFI_DEVICE_INTERFACE =
'org.freedesktop.NetworkManager.Device.Wireless'
NM_ACCESS_POINT_DBUS_INTERFACE =
'org.freedesktop.NetworkManager.AccessPoint'
def get_device_object(device_path):
device_obj = bus.get_object(NM_BUS_NAME, device_path)
return device_obj
def get_device_type(device_path):
device_obj = get_device_object(device_path)
props_interface = dbus.Interface(device_obj,
DBUS_PROPS_DBUS_INTERFACE)
device_type = props_interface.Get(NM_DEVICE_DBUS_INTERFACE,
'DeviceType')
return device_type
def __device_added_cb(device_path):
device_type = get_device_type(device_path)
print 'new device added of type :: ' + str(device_type)
print 'new device path :: ' + device_path
def __device_removed_cb(device_path):
print 'device removed (with path) :: ' + device_path
def listen():
try:
bus = dbus.SystemBus()
obj = bus.get_object(NM_BUS_NAME, NM_PATH)
netmgr = dbus.Interface(obj, NM_DBUS_INTERFACE)
except dbus.DBusException:
logging.debug('%s service not available', NM_BUS_NAME)
return
bus.add_signal_receiver(__device_added_cb,
signal_name='DeviceAdded',
dbus_interface=NM_DBUS_INTERFACE)
bus.add_signal_receiver(__device_removed_cb,
signal_name='DeviceRemoved',
dbus_interface=NM_DBUS_INTERFACE)
listen()
import gobject
gobject.MainLoop().run()
=
I will be grateful for any hints, as to what is going wrong.
Looking forward to a reply.
Regards,
Ajay
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
