Re: [PATCH 3/3] bonding: Apply bonding settings when setting up bonding device
On Wed, 2011-11-09 at 12:16 -0600, Dan Williams wrote: > On Wed, 2011-11-09 at 11:22 +0100, Thomas Graf wrote: > > Adds a new function nm_system_apply_bonding_config() which applies > > the parameters specified in the NMSettingBond object via sysfs. > > > > Calls that function after creating/updating the bonding master > > device. > > > > If a parameter is not specified in the ifcfg the parameter will be > > re-initialized to the default value. This may overwrite changes > > which have been done manually via sysfs but it is the only reliable > > way of setting up the bond. > > > > Supported parameters for now: > > - mode (default: balance-rr) > > - miimon (default: 100) > > - updelay (default: 0) > > - downdelay (default: 0) > > - arp_interval (default: 0) > > - arp_ip_target (default: none) > > Hmm, is there no way to do this via netlink yet? No, it has not been implemented yet. Even when it gets implemented, we will still need this code for backwards compatibility. While on this subject, a bonding alternative called "team" is currently being merged, developed by Jiri Pirko. It's not replacing bonding but offers an alternative implementation. It is likely the future of bonding long term. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
ModemManager: [PATCH] Huawei PDU encoded commands not padded
ModemManager currently encodes the USSD command *141*0# (for MTN South Africa) as "AA182DA6828D00". While this works on some modems, for example the E1820, other modems, for example the E160, require USSD commands that are a multiple of 7 characters long to be padded with 0x0d. Huawei Mobile Partner dashboard software for Windows encodes *141*0# as "AA182DA6828D1A" which works on both the E1820 and the E160. The attached patch pads the USSD command with 0x0d before encoding if it is a multiple of 7 characters long. pdu_ussd_padding.diff Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager: Huawei PDU encoded USSD response truncated to 112 characters
Well, here's the thing, USSD does not tell us how long the decoded string will be, so at the time we call gsm_unpack() we don't know the exact length so we can only assume that it is (bin_len * 8) / 7 as per my previous patch. I attach a new patch which, after decoding, checks whether the last character in a 7-byte block is padding (0x0d) and drops it if it is (for the case when our 7-byte block only contained 7 characters). This works for Huawei modems that use PDU encoded USSD, if it is found that this works for all modems and for SMS as well, perhaps this should be moved into gsm_unpack() in src/mm-charsets.c. > Right, that's my change. Does the USSD path in the plugin know the > length of the text, or does it have to derive the text length from the > length of the hex string? If it doesn't know the length, it's going to > have the same problem I was seeing with SMS messages prior to this > change, where gsm_unpack() couldn't tell if a trailing 7-byte block > had 7 or 8 GSM7 characters in it. > > - Nathan truncated_pdu_ussd_fix_v2.diff Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 0/3] bonding updates
On Wed, 2011-11-09 at 11:22 +0100, Thomas Graf wrote: > A set of follow-up patches for the bonding branch. > > Thomas Graf (3): > netlink-compat: Fix #if check if HAVE_LIBNL1 and HAVE_LIBNL2 are not > defined > system: Convert nm_system_get_link_type() to return an int > bonding: Apply bonding settings when setting up bonding device > > src/nm-netlink-compat.h |2 +- > src/nm-system.c | 102 > +-- > src/nm-system.h | 10 - > src/nm-udev-manager.c | 18 > 4 files changed, 108 insertions(+), 24 deletions(-) Pushed to bonding, thanks. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 3/3] bonding: Apply bonding settings when setting up bonding device
On Wed, 2011-11-09 at 11:22 +0100, Thomas Graf wrote:
> Adds a new function nm_system_apply_bonding_config() which applies
> the parameters specified in the NMSettingBond object via sysfs.
>
> Calls that function after creating/updating the bonding master
> device.
>
> If a parameter is not specified in the ifcfg the parameter will be
> re-initialized to the default value. This may overwrite changes
> which have been done manually via sysfs but it is the only reliable
> way of setting up the bond.
>
> Supported parameters for now:
> - mode (default: balance-rr)
> - miimon (default: 100)
> - updelay (default: 0)
> - downdelay (default: 0)
> - arp_interval (default: 0)
> - arp_ip_target (default: none)
Hmm, is there no way to do this via netlink yet?
Dan
> Thomas Graf
> ---
> src/nm-system.c | 70
> +++
> src/nm-system.h |1 +
> 2 files changed, 71 insertions(+), 0 deletions(-)
>
> diff --git a/src/nm-system.c b/src/nm-system.c
> index 3317eb4..cdfd4da 100644
> --- a/src/nm-system.c
> +++ b/src/nm-system.c
> @@ -1216,6 +1216,74 @@ nm_system_device_set_priority (int ifindex,
> }
> }
>
> +static gboolean
> +set_bond_attr (const char *iface, const char *attr, const char *value)
> +{
> + char file[FILENAME_MAX];
> + gboolean ret;
> +
> + snprintf (file, sizeof(file), "/sys/class/net/%s/bonding/%s",
> + iface, attr);
> +
> + ret = nm_utils_do_sysctl (file, value);
> + if (!ret)
> + nm_log_warn (LOGD_HW, "(%s): failed to set bonding attribute "
> + "'%s' to '%s'", iface, attr, value);
> +
> + return ret;
> +}
> +
> +static gboolean
> +set_bond_attr_int (const char *iface, const char *attr,
> + guint32 value)
> +{
> + char buf[128];
> +
> + snprintf (buf, sizeof(buf), "%u", value);
> +
> + return set_bond_attr (iface, attr, buf);
> +}
> +
> +gboolean
> +nm_system_apply_bonding_config (NMSettingBond *s_bond)
> +{
> + const char *name, *val;
> +
> + name = nm_setting_bond_get_interface_name (s_bond);
> + g_assert (name);
> +
> + if ((val = nm_setting_bond_get_mode (s_bond)))
> + set_bond_attr (name, "mode", val);
> +
> + /*
> + * FIXME:
> + *
> + * ifup-eth contains code to append targets if the value is prefixed
> + * with '+':
> + *
> + * if [ "${key}" = "arp_ip_target" -a "${value:0:1}" != "+" ]; then
> + * OLDIFS=$IFS;
> + * IFS=',';
> + * for arp_ip in $value; do
> + * if ! grep -q $arp_ip /sys/class/net/${DEVICE}/bonding/$key; then
> + * echo +$arp_ip > /sys/class/net/${DEVICE}/bonding/$key
> + * fi
> + * done
> + *
> + * Not sure if this is actually being used and it seems dangerous as
> + * the result is pretty much unforeseeable.
> + */
> + if ((val = nm_setting_bond_get_arp_ip_target (s_bond)))
> + set_bond_attr (name, "arp_ip_target", val);
> +
> + set_bond_attr_int (name, "miimon", nm_setting_bond_get_miimon (s_bond));
> + set_bond_attr_int (name, "downdelay", nm_setting_bond_get_downdelay
> (s_bond));
> + set_bond_attr_int (name, "updelay", nm_setting_bond_get_updelay
> (s_bond));
> + set_bond_attr_int (name, "arp_interval",
> nm_setting_bond_get_arp_interval (s_bond));
> +
> + return TRUE;
> +}
> +
> /**
> * nm_system_add_bonding_master:
> * @setting: bonding setting
> @@ -1244,6 +1312,8 @@ nm_system_add_bonding_master (NMSettingBond *setting)
> return FALSE;
> }
>
> + nm_system_apply_bonding_config (setting);
> +
> return TRUE;
> }
>
> diff --git a/src/nm-system.h b/src/nm-system.h
> index f151e90..aa175a6 100644
> --- a/src/nm-system.h
> +++ b/src/nm-system.h
> @@ -91,6 +91,7 @@ gbooleannm_system_iface_set_mtu
> (int ifindex, guint32 mtu);
>
> gboolean nm_system_iface_set_mac (int ifindex,
> const struct ether_addr *mac);
>
> +gboolean nm_system_apply_bonding_config (NMSettingBond
> *s_bond);
> gboolean nm_system_add_bonding_master(NMSettingBond
> *setting);
> gboolean nm_system_iface_enslave (NMDevice *slave,
> NMDevice *master);
> gboolean nm_system_iface_release (NMDevice *slave,
> NMDevice *master);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Saving agent-owned secrets for newly created connections
On Wed, 2011-11-09 at 17:13 +0100, Jirka Klimes wrote: > Hello, > > attached is a patch for sending secrets to agents when a new connection is > created (AddConnection, AddAndActivateConnection). > > At present, when a new connection is created, the secrets are not sent to > agents and thus not saved. One has to edit the connection again. It is easily > reproducible by adding a VPN connection. When it is opened again in the > editor, the secrets are not there. Hmm, could we do the save from pk_add_cb() and make the patch smaller? That way nm_settings_connection_save_agent_secrets() could be made private to nm-settings.c. And we wouldn't have to pass the caller_uid to the nm_settings_add_connection() callback, which saves some churn. Ordering might also be interesting here; since this could trigger a SaveSecrets before the agent has been able to process the new connection, meaning that the agent may not actually have grabbed the connection yet (since that's another dbus call) when SaveSecrets comes in. I don't think that's a problem in practice for the nm-applet agent but it might be for others. Not sure if there's anything we can do about it though since the ordering would be correct. One thing we should probably do (later though) is not call SaveSecrets at all if there aren't any secrets left to send after filtering for AGENT_OWNED secrets. Shouldn't have any real effect, but would be more "correct". Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Pass DBUS_SYSTEM_BUS_ADDRESS environment variable to dhclient.
On Sun, 2011-11-06 at 16:13 +, David Röthlisberger wrote: > Pass DBUS_SYSTEM_BUS_ADDRESS environment variable to dhclient. > > So that dhclient will, in turn, pass it to the action script (the action > script tries to send a DBus signal to NetworkManager over the system bus). > > Dhclient "execve"s the action script with a hand-constructed environment that > only includes specific variables, plus whatever is passed to dhclient with > "-e". > > As far as I know, dhcpcd has no option equivalent to dhclient's "-e". > > This patch is on the NM_0_8 branch. Pushed to 0.8 and 0.9, thanks. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] Saving agent-owned secrets for newly created connections
Hello,
attached is a patch for sending secrets to agents when a new connection is
created (AddConnection, AddAndActivateConnection).
At present, when a new connection is created, the secrets are not sent to
agents and thus not saved. One has to edit the connection again. It is easily
reproducible by adding a VPN connection. When it is opened again in the
editor, the secrets are not there.
Jirka
From 08614365ba858a090d11cafdf2f506419678b4f0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ji=C5=99=C3=AD=20Klime=C5=A1?=
Date: Wed, 9 Nov 2011 16:48:35 +0100
Subject: [PATCH] settings: send agent-owned secrets also for newly created
connections
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
We have to send agent-owned secrets to agents via SaveSecrets() D-Bus call for
newly created connections, the same way we do for connection updates.
Without that secrets aren't saved for new created VPN connections, for example.
The secrets was only sent after editing the connection afterwards, i.e.
updating it.
Signed-off-by: Jiří Klimeš
---
src/nm-manager.c |4 +++
src/settings/nm-settings-connection.c | 37 +++-
src/settings/nm-settings-connection.h |3 ++
src/settings/nm-settings.c| 20 -
src/settings/nm-settings.h|1 +
5 files changed, 44 insertions(+), 21 deletions(-)
diff --git a/src/nm-manager.c b/src/nm-manager.c
index 475344a..923d511 100644
--- a/src/nm-manager.c
+++ b/src/nm-manager.c
@@ -2124,6 +2124,7 @@ activation_add_done (NMSettings *self,
NMSettingsConnection *connection,
GError *error,
DBusGMethodInvocation *context,
+ gulong caller_uid,
gpointer user_data)
{
PendingActivation *pending = user_data;
@@ -2131,6 +2132,9 @@ activation_add_done (NMSettings *self,
if (error)
pending_activation_destroy (pending, error, NULL);
else {
+ /* Send agent-owned secrets to the agents */
+ nm_settings_connection_save_agent_secrets (connection, caller_uid);
+
/* Save the new connection's D-Bus path */
pending->connection_path = g_strdup (nm_connection_get_path (NM_CONNECTION (connection)));
diff --git a/src/settings/nm-settings-connection.c b/src/settings/nm-settings-connection.c
index cdad832..647d7f8 100644
--- a/src/settings/nm-settings-connection.c
+++ b/src/settings/nm-settings-connection.c
@@ -1098,9 +1098,27 @@ impl_settings_connection_get_settings (NMSettingsConnection *self,
auth_start (self, context, NULL, get_settings_auth_cb, NULL);
}
+void
+nm_settings_connection_save_agent_secrets (NMSettingsConnection *self,
+ gulong caller_uid)
+{
+ NMSettingsConnectionPrivate *priv = NM_SETTINGS_CONNECTION_GET_PRIVATE (self);
+ NMConnection *for_agent;
+
+ /* Dupe the connection so we can clear out non-agent-owned secrets,
+ * as agent-owned secrets are the only ones we send back be saved.
+ * Only send secrets to agents of the same UID that called update too.
+ */
+ for_agent = nm_connection_duplicate (NM_CONNECTION (self));
+ nm_connection_clear_secrets_with_flags (for_agent,
+ secrets_filter_cb,
+ GUINT_TO_POINTER (NM_SETTING_SECRET_FLAG_AGENT_OWNED));
+ nm_agent_manager_save_secrets (priv->agent_mgr, for_agent, TRUE, caller_uid);
+ g_object_unref (for_agent);
+}
+
typedef struct {
DBusGMethodInvocation *context;
- NMAgentManager *agent_mgr;
gulong sender_uid;
} UpdateInfo;
@@ -1110,26 +1128,17 @@ con_update_cb (NMSettingsConnection *self,
gpointer user_data)
{
UpdateInfo *info = user_data;
- NMConnection *for_agent;
if (error)
dbus_g_method_return_error (info->context, error);
else {
- /* Dupe the connection so we can clear out non-agent-owned secrets,
- * as agent-owned secrets are the only ones we send back be saved.
- * Only send secrets to agents of the same UID that called update too.
- */
- for_agent = nm_connection_duplicate (NM_CONNECTION (self));
- nm_connection_clear_secrets_with_flags (for_agent,
- secrets_filter_cb,
- GUINT_TO_POINTER (NM_SETTING_SECRET_FLAG_AGENT_OWNED));
- nm_agent_manager_save_secrets (info->agent_mgr, for_agent, TRUE, info->sender_uid);
- g_object_unref (for_agent);
+
+ /* Send agent-owned secrets to the agents */
+ nm_settings_connection_save_agent_secrets (self, info->sender_uid);
dbus_g_method_return (info->context);
}
- g_object_unref (info->agent_mgr);
memset (info, 0, sizeof (*info));
g_free (info);
}
@@ -1141,7 +1150,6 @@ update_auth_cb (NMSettingsConnection *self,
GError *error,
gpointer data)
{
- NMSettingsConnectionPrivate *priv = NM_SETTINGS_CONNECTION_GET_PRIVATE (self);
NMConnection *new_set
Re: ModemManager: Huawei PDU encoded USSD response truncated to 112 characters
Right, that's my change. Does the USSD path in the plugin know the
length of the text, or does it have to derive the text length from the
length of the hex string? If it doesn't know the length, it's going to
have the same problem I was seeing with SMS messages prior to this
change, where gsm_unpack() couldn't tell if a trailing 7-byte block
had 7 or 8 GSM7 characters in it.
- Nathan
On Wed, Nov 9, 2011 at 5:48 AM, Graham Inggs wrote:
> I've found that prior to the following commit:
>
> http://cgit.freedesktop.org/ModemManager/ModemManager/commit/src/mm-charsets.c?id=d05c87e4c80f1a56a613241d14de4faeb0a8304a
>
> ...gsm_unpack() in src/mm-charsets.c took the number of encoded characters
> as input, now it takes the number of decoded characters as input.
>
>
> On 07/11/2011 21:50, Graham Inggs wrote:
>>
>> I believe the cause of this problem is that the output string of
>> gsm_unpack() needs to be larger than the input string. We get 8
>> characters out for every 7 input characters.
>>
>> I have attached a simple patch to /plugins/mm-modem-huawei-gsm.c which
>> results in the full USSD response being returned.
>>
>> I am not sure that this patch is the correct fix. It may be that
>> gsm_unpack() in src/mm-charsets.c needs take the 8/7 growth into
>> account when sizing the output array and returning the unpacked size.
>> Would someone more familiar with src/mm-charsets.c offer some guidance
>> please?
>>
>>
>> On Fri, Nov 4, 2011 at 8:44 AM, Graham Inggs
>> wrote:
>>>
>>> Tested with Huawei E1820.
>>>
>>> ussdresult = gsmussd.Initiate("*101#")
>>> print "ussd response: %s" % ussdresult
>>>
>>> ussd response: Balance = R 9.50 Expiry date:02/05/2031.On-Net Minutes
>>> = 01:16:00.Free SMS's = 51.Free Data = 100.00 MB.Free Da
>>>
>>> The full response should have been:
>>>
>>> Balance = R 9.50 Expiry date:02/05/2031.On-Net Minutes =
>>> 01:16:00.Free SMS's = 51.Free Data = 100.00 MB.Free Data = 2007.44 MB.
>>>
>>> Partial ModemManager log:
>>>
>>> modem-manager[3316]: [1320384816.466178]
>>> [mm-at-serial-port.c:298] debug_log(): (ttyUSB0): -->
>>> 'AT+CUSD=1,"AA182C3602",15'
>>> modem-manager[3316]: [1320384816.504610]
>>> [mm-at-serial-port.c:298] debug_log(): (ttyUSB0):<--
>>> 'OK'
>>> modem-manager[3316]: [1320384816.818950]
>>> [mm-at-serial-port.c:298] debug_log(): (ttyUSB2):<--
>>> '^RSSI:16'
>>> modem-manager[3316]: [1320384816.819316]
>>> [mm-at-serial-port.c:298] debug_log(): (ttyUSB2):<--
>>> '^CSNR:-77,-7'
>>> modem-manager[3316]: [1320384818.431324]
>>> [mm-at-serial-port.c:298] debug_log(): (ttyUSB2):<-- '+CUSD:
>>>
>>> 0,"C2303BEC1E97413D90149473D5602050110F4FCBF32072985ED6C1642F58ED2583CD62AEA7BBE52CD341CDB4BB4E2FCF413D102CA68BD9743098CB282F9741D3E6F43407F540B598CB282F9741C4303D0CEA816230980B060335852EA3BC5C0611C3F430A80792C16037178D066A0A5D",15'
>>>
>
> ___
> 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: mobile-broadband-provider-info: Request for msisdn-query tag to be added
Hi Marius, > >> There is often a need to query the MSISDN (mobile telephone number) > >> associated with a GSM SIM card, for example when doing a pre-paid > >> top-up over the internet or when calling the network operator's > >> technical support. Because this number can change, the only reliable > >> way of obtaining it is directly from the network operator. > > you know that with a proper provisioned SIM card (or some additional STK > > magic) you can read this number from the EF of your SIM card. > > But it often does not work. My Android phone has in system information a > field for my phone number, but it is empty. as I said, you need to have a SIM card from a provider that cares to get this right. Or ensures that STK updates these fields. Also in a lot of cases you could just write that specific EF entry by yourself with your phone number. Regards Marcel ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager: Huawei PDU encoded USSD response truncated to 112 characters
I've found that prior to the following commit:
http://cgit.freedesktop.org/ModemManager/ModemManager/commit/src/mm-charsets.c?id=d05c87e4c80f1a56a613241d14de4faeb0a8304a
...gsm_unpack() in src/mm-charsets.c took the number of encoded
characters as input, now it takes the number of decoded characters as input.
On 07/11/2011 21:50, Graham Inggs wrote:
I believe the cause of this problem is that the output string of
gsm_unpack() needs to be larger than the input string. We get 8
characters out for every 7 input characters.
I have attached a simple patch to /plugins/mm-modem-huawei-gsm.c which
results in the full USSD response being returned.
I am not sure that this patch is the correct fix. It may be that
gsm_unpack() in src/mm-charsets.c needs take the 8/7 growth into
account when sizing the output array and returning the unpacked size.
Would someone more familiar with src/mm-charsets.c offer some guidance
please?
On Fri, Nov 4, 2011 at 8:44 AM, Graham Inggs wrote:
Tested with Huawei E1820.
ussdresult = gsmussd.Initiate("*101#")
print "ussd response: %s" % ussdresult
ussd response: Balance = R 9.50 Expiry date:02/05/2031.On-Net Minutes
= 01:16:00.Free SMS's = 51.Free Data = 100.00 MB.Free Da
The full response should have been:
Balance = R 9.50 Expiry date:02/05/2031.On-Net Minutes =
01:16:00.Free SMS's = 51.Free Data = 100.00 MB.Free Data = 2007.44 MB.
Partial ModemManager log:
modem-manager[3316]: [1320384816.466178]
[mm-at-serial-port.c:298] debug_log(): (ttyUSB0): -->
'AT+CUSD=1,"AA182C3602",15'
modem-manager[3316]: [1320384816.504610]
[mm-at-serial-port.c:298] debug_log(): (ttyUSB0):<--
'OK'
modem-manager[3316]: [1320384816.818950]
[mm-at-serial-port.c:298] debug_log(): (ttyUSB2):<--
'^RSSI:16'
modem-manager[3316]: [1320384816.819316]
[mm-at-serial-port.c:298] debug_log(): (ttyUSB2):<--
'^CSNR:-77,-7'
modem-manager[3316]: [1320384818.431324]
[mm-at-serial-port.c:298] debug_log(): (ttyUSB2):<-- '+CUSD:
0,"C2303BEC1E97413D90149473D5602050110F4FCBF32072985ED6C1642F58ED2583CD62AEA7BBE52CD341CDB4BB4E2FCF413D102CA68BD9743098CB282F9741D3E6F43407F540B598CB282F9741C4303D0CEA816230980B060335852EA3BC5C0611C3F430A80792C16037178D066A0A5D",15'
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 3/3] bonding: Apply bonding settings when setting up bonding device
Adds a new function nm_system_apply_bonding_config() which applies
the parameters specified in the NMSettingBond object via sysfs.
Calls that function after creating/updating the bonding master
device.
If a parameter is not specified in the ifcfg the parameter will be
re-initialized to the default value. This may overwrite changes
which have been done manually via sysfs but it is the only reliable
way of setting up the bond.
Supported parameters for now:
- mode (default: balance-rr)
- miimon (default: 100)
- updelay (default: 0)
- downdelay (default: 0)
- arp_interval (default: 0)
- arp_ip_target (default: none)
Thomas Graf
---
src/nm-system.c | 70 +++
src/nm-system.h |1 +
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/src/nm-system.c b/src/nm-system.c
index 3317eb4..cdfd4da 100644
--- a/src/nm-system.c
+++ b/src/nm-system.c
@@ -1216,6 +1216,74 @@ nm_system_device_set_priority (int ifindex,
}
}
+static gboolean
+set_bond_attr (const char *iface, const char *attr, const char *value)
+{
+ char file[FILENAME_MAX];
+ gboolean ret;
+
+ snprintf (file, sizeof(file), "/sys/class/net/%s/bonding/%s",
+ iface, attr);
+
+ ret = nm_utils_do_sysctl (file, value);
+ if (!ret)
+ nm_log_warn (LOGD_HW, "(%s): failed to set bonding attribute "
+"'%s' to '%s'", iface, attr, value);
+
+ return ret;
+}
+
+static gboolean
+set_bond_attr_int (const char *iface, const char *attr,
+ guint32 value)
+{
+ char buf[128];
+
+ snprintf (buf, sizeof(buf), "%u", value);
+
+ return set_bond_attr (iface, attr, buf);
+}
+
+gboolean
+nm_system_apply_bonding_config (NMSettingBond *s_bond)
+{
+ const char *name, *val;
+
+ name = nm_setting_bond_get_interface_name (s_bond);
+ g_assert (name);
+
+ if ((val = nm_setting_bond_get_mode (s_bond)))
+ set_bond_attr (name, "mode", val);
+
+ /*
+* FIXME:
+*
+* ifup-eth contains code to append targets if the value is prefixed
+* with '+':
+*
+* if [ "${key}" = "arp_ip_target" -a "${value:0:1}" != "+" ]; then
+* OLDIFS=$IFS;
+* IFS=',';
+* for arp_ip in $value; do
+* if ! grep -q $arp_ip /sys/class/net/${DEVICE}/bonding/$key; then
+* echo +$arp_ip > /sys/class/net/${DEVICE}/bonding/$key
+* fi
+* done
+*
+* Not sure if this is actually being used and it seems dangerous as
+* the result is pretty much unforeseeable.
+*/
+ if ((val = nm_setting_bond_get_arp_ip_target (s_bond)))
+ set_bond_attr (name, "arp_ip_target", val);
+
+ set_bond_attr_int (name, "miimon", nm_setting_bond_get_miimon (s_bond));
+ set_bond_attr_int (name, "downdelay", nm_setting_bond_get_downdelay
(s_bond));
+ set_bond_attr_int (name, "updelay", nm_setting_bond_get_updelay
(s_bond));
+ set_bond_attr_int (name, "arp_interval",
nm_setting_bond_get_arp_interval (s_bond));
+
+ return TRUE;
+}
+
/**
* nm_system_add_bonding_master:
* @setting: bonding setting
@@ -1244,6 +1312,8 @@ nm_system_add_bonding_master (NMSettingBond *setting)
return FALSE;
}
+ nm_system_apply_bonding_config (setting);
+
return TRUE;
}
diff --git a/src/nm-system.h b/src/nm-system.h
index f151e90..aa175a6 100644
--- a/src/nm-system.h
+++ b/src/nm-system.h
@@ -91,6 +91,7 @@ gboolean nm_system_iface_set_mtu
(int ifindex, guint32 mtu);
gboolean nm_system_iface_set_mac (int ifindex,
const struct ether_addr *mac);
+gboolean nm_system_apply_bonding_config (NMSettingBond
*s_bond);
gboolean nm_system_add_bonding_master(NMSettingBond
*setting);
gboolean nm_system_iface_enslave (NMDevice *slave,
NMDevice *master);
gboolean nm_system_iface_release (NMDevice *slave,
NMDevice *master);
--
1.7.6.4
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 2/3] system: Convert nm_system_get_link_type() to return an int
Kills the strdup() and avoids having the caller free the memory. Also renames
the function to nm_system_get_iface_type() since "link" is not a common term
in NM.
Signed-off-by: Thomas Graf
---
src/nm-system.c | 32 +++-
src/nm-system.h |9 -
src/nm-udev-manager.c | 18 +-
3 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/src/nm-system.c b/src/nm-system.c
index 709a08b..3317eb4 100644
--- a/src/nm-system.c
+++ b/src/nm-system.c
@@ -1423,33 +1423,39 @@ out:
}
/**
- * nm_system_get_link_type:
- * @name: name of link
+ * nm_system_get_iface_type:
+ * @name: name of interface
*
- * Lookup virtual link type. The returned string is allocated and needs
- * to be freed after usage.
+ * Lookup the type of an interface
*
- * Returns: Name of virtual link type or NULL if not a virtual link.
+ * Returns: Interface type (NM_IFACE_TYPE_*) or NM_IFACE_TYPE_UNSPEC.
**/
-char *
-nm_system_get_link_type (const char *name)
+int
+nm_system_get_iface_type (const char *name)
{
struct rtnl_link *result;
struct nl_sock *nlh;
char *type;
+ int res = NM_IFACE_TYPE_UNSPEC;
nlh = nm_netlink_get_default_handle ();
if (!nlh)
- return NULL;
+ goto out;
if (rtnl_link_get_kernel (nlh, 0, name, &result) < 0)
- return NULL;
+ goto out;
- if ((type = rtnl_link_get_type (result)))
- type = g_strdup (type);
+ type = rtnl_link_get_type (result);
- rtnl_link_put (result);
+ if (!g_strcmp0 (type, "bond"))
+ res = NM_IFACE_TYPE_BOND;
+ else if (!g_strcmp0 (type, "vlan"))
+ res = NM_IFACE_TYPE_VLAN;
+ else if (!g_strcmp0 (type, "dummy"))
+ res = NM_IFACE_TYPE_DUMMY;
- return type;
+ rtnl_link_put (result);
+out:
+ return res;
}
diff --git a/src/nm-system.h b/src/nm-system.h
index 339dfa7..f151e90 100644
--- a/src/nm-system.h
+++ b/src/nm-system.h
@@ -95,6 +95,13 @@ gboolean nm_system_add_bonding_master
(NMSettingBond *setting);
gboolean nm_system_iface_enslave (NMDevice *slave,
NMDevice *master);
gboolean nm_system_iface_release (NMDevice *slave,
NMDevice *master);
-char * nm_system_get_link_type (const char *name);
+enum {
+ NM_IFACE_TYPE_UNSPEC = 0,
+ NM_IFACE_TYPE_BOND,
+ NM_IFACE_TYPE_VLAN,
+ NM_IFACE_TYPE_DUMMY,
+};
+
+int nm_system_get_iface_type(const char *name);
#endif
diff --git a/src/nm-udev-manager.c b/src/nm-udev-manager.c
index ede39bb..55e1517 100644
--- a/src/nm-udev-manager.c
+++ b/src/nm-udev-manager.c
@@ -431,15 +431,15 @@ device_creator (NMUdevManager *manager,
}
if (!driver) {
- char *type;
-
- type = nm_system_get_link_type (ifname);
- if (type) {
- if (g_strcmp0 (type, "bond") == 0)
- driver = "bonding";
- g_free (type);
- } else if (g_str_has_prefix (ifname, "easytether")) {
- driver = "easytether";
+ switch (nm_system_get_iface_type (ifname)) {
+ case NM_IFACE_TYPE_BOND:
+ driver = "bonding";
+ break;
+
+ default:
+ if (g_str_has_prefix (ifname, "easytether"))
+ driver = "easytether";
+ break;
}
if (!driver) {
--
1.7.6.4
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 1/3] netlink-compat: Fix #if check if HAVE_LIBNL1 and HAVE_LIBNL2 are not defined
Need to use #if defined HAVE_LIBNL1 instead of #if HAVE_LIBNL1. Signed-off-by: Thomas Graf --- src/nm-netlink-compat.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/nm-netlink-compat.h b/src/nm-netlink-compat.h index 5038851..404a85f 100644 --- a/src/nm-netlink-compat.h +++ b/src/nm-netlink-compat.h @@ -207,7 +207,7 @@ __nl_cache_include (struct nl_cache *cache, struct nl_object *obj, change_func_t #endif /* HAVE_LIBNL1 */ /* Stuff that only libnl3 has */ -#if HAVE_LIBNL1 || HAVE_LIBNL2 +#if (defined HAVE_LIBNL1 || defined HAVE_LIBNL2) static inline int rtnl_link_bond_add (struct nl_sock *h, const char *name, void *data) -- 1.7.6.4 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH 0/3] bonding updates
A set of follow-up patches for the bonding branch. Thomas Graf (3): netlink-compat: Fix #if check if HAVE_LIBNL1 and HAVE_LIBNL2 are not defined system: Convert nm_system_get_link_type() to return an int bonding: Apply bonding settings when setting up bonding device src/nm-netlink-compat.h |2 +- src/nm-system.c | 102 +-- src/nm-system.h | 10 - src/nm-udev-manager.c | 18 4 files changed, 108 insertions(+), 24 deletions(-) -- 1.7.6.4 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: mobile-broadband-provider-info: Request for msisdn-query tag to be added
Den 09. nov. 2011 08:52, skrev Marcel Holtmann: Hi Graham, There is often a need to query the MSISDN (mobile telephone number) associated with a GSM SIM card, for example when doing a pre-paid top-up over the internet or when calling the network operator's technical support. Because this number can change, the only reliable way of obtaining it is directly from the network operator. you know that with a proper provisioned SIM card (or some additional STK magic) you can read this number from the EF of your SIM card. But it often does not work. My Android phone has in system information a field for my phone number, but it is empty. -- Marius ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: problems with fasttrack xtend fxt009
Hi, On 08/11/11 12:22, Thomas Bechtold wrote: I'm unable to get a working connection (see MM-Log). i talked to vodafone and they had problems with the apn 'web.vodafone.de'. After the connection, the modem does not answer to any AT-commands (see the end of MM-Log). i tried an older MM version (git snapshot from 20110608t111033) and with that version, the modems sends responses even if the apn does not work. after i changed the apn to 'event.vodafone.de', i got a connection (with the git version from 20110608t111033). i still have to try the modem with event.vodafone.de and the current git snapshot. cheers, Tom I tried to enable the modem with "nmcli con up id ModemGSM". See NM-Log for network-manager details. The NetworkManager config for "ModemGSM" is: # cat /etc/NetworkManager/system-connections/ModemGSM [connection] id=ModemGSM uuid=baa2af1b-e21e-7bcf-f1ac-1a775c46ddc3 type=gsm autoconnect=false [ipv4] method=auto [gsm] number=#99* username=vodafone password=vodafone apn=web.vodafone.de pin= [serial] baud=115200 Ideas how to solve the problem? Cheers, Tom # MM-Log ### # pkill modem-manager && modem-manager --debug --log-level=DEBUG modem-manager[2800]: [1320750454.293239] [main.c:167] main(): ModemManager (version 0.5.999) starting... modem-manager[2800]: [1320750454.549302] [mm-manager.c:158] found_plugin(): Loaded plugin 'Option' modem-manager[2800]: [1320750454.550114] [mm-manager.c:158] found_plugin(): Loaded plugin 'X22X' modem-manager[2800]: [1320750454.550857] [mm-manager.c:158] found_plugin(): Loaded plugin 'Ericsson MBM' modem-manager[2800]: [1320750454.574424] [mm-manager.c:158] found_plugin(): Loaded plugin 'Sierra' modem-manager[2800]: [1320750454.574749] [mm-manager.c:158] found_plugin(): Loaded plugin 'Linktop' modem-manager[2800]: [1320750454.575024] [mm-manager.c:158] found_plugin(): Loaded plugin 'AnyData' modem-manager[2800]: [1320750454.575285] [mm-manager.c:158] found_plugin(): Loaded plugin 'Longcheer' modem-manager[2800]: [1320750454.575547] [mm-manager.c:158] found_plugin(): Loaded plugin 'Wavecom' modem-manager[2800]: [1320750454.575807] [mm-manager.c:158] found_plugin(): Loaded plugin 'Novatel' modem-manager[2800]: [1320750454.576068] [mm-manager.c:158] found_plugin(): Loaded plugin 'SimTech' modem-manager[2800]: [1320750454.576328] [mm-manager.c:158] found_plugin(): Loaded plugin 'Nokia' modem-manager[2800]: [1320750454.576585] [mm-manager.c:158] found_plugin(): Loaded plugin 'Samsung' modem-manager[2800]: [1320750454.576842] [mm-manager.c:158] found_plugin(): Loaded plugin 'Gobi' modem-manager[2800]: [1320750454.577308] [mm-manager.c:158] found_plugin(): Loaded plugin 'Huawei' modem-manager[2800]: [1320750454.578022] [mm-manager.c:158] found_plugin(): Loaded plugin 'MotoC' modem-manager[2800]: [1320750454.578747] [mm-manager.c:158] found_plugin(): Loaded plugin 'ZTE' modem-manager[2800]: [1320750454.579459] [mm-manager.c:158] found_plugin(): Loaded plugin 'Option High-Speed' modem-manager[2800]: [1320750454.580178] [mm-manager.c:158] found_plugin(): Loaded plugin 'Cinterion' modem-manager[2800]: [1320750454.580900] [mm-manager.c:158] found_plugin(): Loaded plugin 'Generic' modem-manager[2800]: [1320750454.585689] [mm-manager.c:210] load_plugins(): Successfully loaded 19 plugins modem-manager[2800]: [1320750454.596035] [mm-manager.c:1030] mm_manager_start(): Starting device scan... modem-manager[2800]: [1320750454.672028] [mm-manager.c:848] device_added(): (tty/ttyS0): port's parent platform driver is not whitelisted modem-manager[2800]: [1320750454.720729] [mm-manager.c:848] device_added(): (tty/ttyS2): port's parent platform driver is not whitelisted modem-manager[2800]: [1320750454.723998] [mm-manager.c:848] device_added(): (tty/ttyS4): port's parent platform driver is not whitelisted modem-manager[2800]: [1320750454.789874] [mm-manager.c:848] device_added(): (net/usb0): port's parent platform driver is not whitelisted modem-manager[2800]: [1320750454.792532] [mm-manager.c:1048] mm_manager_start(): Finished device scan... modem-manager[2800]: [1320750454.793574] [mm-serial-port.c:805] mm_serial_port_open(): (ttyACM0) opening serial port... modem-manager[2800]: [1320750454.796262] [mm-serial-port.c:874] mm_serial_port_open(): (ttyACM0) device open count is 1 (open) modem-manager[2800]: [1320750454.797095] [mm-plugin-base.c:1045] try_open(): (ttyACM0): probe requested by plugin 'Wavecom' modem-manager[2800]: [1320750454.799453] [mm-serial-port.c:805] mm_serial_port_open(): (ttyS1) opening serial port... modem-manager[2800]: [1320750454.800870] [mm-serial-port.c:874] mm_serial_port_open(): (ttyS1) device open count is 1 (open) modem-manager[2800]: [1320750454.801855] [mm-plugin-base.c:1045] try_open(): (ttyS1): probe requested by plugin 'Cinterion' modem-manager[2800]: [1320750454.913371] [mm-at-serial-port.c:298] debug_log(): (ttyACM0): --> 'AT+GCAP' modem-manager[2800]: [1320750454.9145
