Re: [MM] [PATCH v3] iface-modem-3gpp: defer registration state update when registration is lost
I've rebased patch v3 on top of HEAD, so that patch v4 can be applied cleanly on HEAD. Dan, how do you think about the timeout? Thanks, Ben On Thu, Feb 14, 2013 at 11:48 PM, Aleksander Morgado wrote: > > Looks better now. > > Dan, any further comments? You were concerned about the value of the > timeout IIRC, should we increase it? I don't think there should be any > problem with having a longer timeout, as we're just hiding the real > registration state to the whole system, so a longer timeout here > shouldn't break anything. > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
[MM] [PATCH v4] iface-modem-3gpp: defer registration state update when registration is lost
This patch defers the update of 3GPP registration state by 15 seconds
when the registration state changes from 'registered' (home / roaming)
to 'searching'. This allows a temporary loss of 3GPP registration to
recover itself when relying on ModemManager to explicitly disconnect and
reconnect to the network.
---
I rebase patch v3 on top of HEAD, so that this v4 patch can be applied cleanly
on HEAD.
src/mm-iface-modem-3gpp.c | 122 ++
1 file changed, 102 insertions(+), 20 deletions(-)
diff --git a/src/mm-iface-modem-3gpp.c b/src/mm-iface-modem-3gpp.c
index 7117e9c..fa8da1a 100644
--- a/src/mm-iface-modem-3gpp.c
+++ b/src/mm-iface-modem-3gpp.c
@@ -29,6 +29,7 @@
#include "mm-log.h"
#define REGISTRATION_CHECK_TIMEOUT_SEC 30
+#define DEFERRED_REGISTRATION_STATE_UPDATE_TIMEOUT_SEC 15
#define SUBSYSTEM_3GPP "3gpp"
@@ -73,6 +74,8 @@ typedef struct {
MMModem3gppRegistrationState cs;
MMModem3gppRegistrationState ps;
MMModem3gppRegistrationState eps;
+MMModem3gppRegistrationState deferred_new_state;
+guint deferred_update_id;
gboolean manual_registration;
GCancellable *pending_registration_cancellable;
gboolean reloading_operator;
@@ -85,6 +88,9 @@ registration_state_context_free (RegistrationStateContext
*ctx)
g_cancellable_cancel (ctx->pending_registration_cancellable);
g_object_unref (ctx->pending_registration_cancellable);
}
+if (ctx->deferred_update_id) {
+g_source_remove (ctx->deferred_update_id);
+}
g_slice_free (RegistrationStateContext, ctx);
}
@@ -104,6 +110,7 @@ get_registration_state_context (MMIfaceModem3gpp *self)
ctx->cs = MM_MODEM_3GPP_REGISTRATION_STATE_UNKNOWN;
ctx->ps = MM_MODEM_3GPP_REGISTRATION_STATE_UNKNOWN;
ctx->eps = MM_MODEM_3GPP_REGISTRATION_STATE_UNKNOWN;
+ctx->deferred_new_state = MM_MODEM_3GPP_REGISTRATION_STATE_UNKNOWN;
g_object_set_qdata_full (
G_OBJECT (self),
@@ -1033,25 +1040,98 @@ update_registration_reload_current_operator_ready
(MMIfaceModem3gpp *self,
}
static void
+update_non_registered_state (MMIfaceModem3gpp *self,
+ MMModem3gppRegistrationState old_state,
+ MMModem3gppRegistrationState new_state)
+{
+/* Not registered neither in home nor roaming network */
+mm_iface_modem_3gpp_clear_current_operator (self);
+
+/* The property in the interface is bound to the property
+ * in the skeleton, so just updating here is enough */
+g_object_set (self,
+ MM_IFACE_MODEM_3GPP_REGISTRATION_STATE, new_state,
+ NULL);
+
+mm_iface_modem_update_subsystem_state (
+MM_IFACE_MODEM (self),
+SUBSYSTEM_3GPP,
+(new_state == MM_MODEM_3GPP_REGISTRATION_STATE_SEARCHING ?
+ MM_MODEM_STATE_SEARCHING :
+ MM_MODEM_STATE_ENABLED),
+MM_MODEM_STATE_CHANGE_REASON_UNKNOWN);
+}
+
+static gboolean
+run_deferred_registration_state_update (MMIfaceModem3gpp *self)
+{
+MMModem3gppRegistrationState old_state =
MM_MODEM_3GPP_REGISTRATION_STATE_UNKNOWN;
+MMModem3gppRegistrationState new_state;
+RegistrationStateContext *ctx;
+
+ctx = get_registration_state_context (self);
+ctx->deferred_update_id = 0;
+
+g_object_get (self,
+ MM_IFACE_MODEM_3GPP_REGISTRATION_STATE, &old_state,
+ NULL);
+new_state = ctx->deferred_new_state;
+
+/* Only set new state if different */
+if (new_state == old_state)
+return FALSE;
+
+mm_info ("Modem %s: (deferred) 3GPP Registration state changed (%s -> %s)",
+ g_dbus_object_get_object_path (G_DBUS_OBJECT (self)),
+ mm_modem_3gpp_registration_state_get_string (old_state),
+ mm_modem_3gpp_registration_state_get_string (new_state));
+
+update_non_registered_state (self, old_state, new_state);
+
+return FALSE;
+}
+
+static void
update_registration_state (MMIfaceModem3gpp *self,
MMModem3gppRegistrationState new_state)
{
MMModem3gppRegistrationState old_state =
MM_MODEM_3GPP_REGISTRATION_STATE_UNKNOWN;
+RegistrationStateContext *ctx;
g_object_get (self,
MM_IFACE_MODEM_3GPP_REGISTRATION_STATE, &old_state,
NULL);
+ctx = get_registration_state_context (self);
+g_assert (ctx);
+
+if (ctx->deferred_update_id != 0) {
+/* If there is already a deferred 'registration loss' state update and
the new update
+ * is not a registered state, update the deferred state update without
extending the
+ * timeout. */
+if (new_state != MM_MODEM_3GPP_REGISTRATION_STATE_HOME &&
+new_state != MM_MODEM_3GPP_REGISTRATION_STATE_ROAMING) {
+mm_info ("Modem %s: 3GPP Registration state changed (%s -> %s),
update deferred",
+ g_dbus_object_get_object_path (G_DBUS_OBJECT (
Re: v1.0.8 & DUID
On Fri, 2013-02-15 at 16:16 -0500, Gene Czarcinski wrote: > On 02/15/2013 03:28 PM, Dan Williams wrote: > > On Fri, 2013-02-15 at 14:32 -0500, Gene Czarcinski wrote: > >> >Although there is a v1.0.8 tag in the NM git, there is still hope since > >> >there has not been a Release Announcement yet. > > Hmm, I don't see a 1.0.8 or a 1.0.2. The latest release was 0.9.6.4, > > and the next release will be 0.9.8. This next release will be from > > this branch: > Oops ... trying to work too many different packages at the same time: > NetworkManager-0.9.7.997; libvirt-1.0.2 ... but the same topic: DUID Yeah, like I said, your patches and my cleanups got pushed to both 0.9.8 and master branches, so they'll show up in the next release. Thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: v1.0.8 & DUID
On 02/15/2013 03:28 PM, Dan Williams wrote: On Fri, 2013-02-15 at 14:32 -0500, Gene Czarcinski wrote: >Although there is a v1.0.8 tag in the NM git, there is still hope since >there has not been a Release Announcement yet. Hmm, I don't see a 1.0.8 or a 1.0.2. The latest release was 0.9.6.4, and the next release will be 0.9.8. This next release will be from this branch: Oops ... trying to work too many different packages at the same time: NetworkManager-0.9.7.997; libvirt-1.0.2 ... but the same topic: DUID Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with Sierra MC 8790 after kernel upgrade to 3.7.x
On Fri, 2013-02-15 at 09:26 +0100, Harald Jung wrote: > I've cleaned up to log, because i have no access to the notebook at the > moment. > ipv6 should be deactived and is not activated in the config. Once you have access to the notebook again, can you stop MM the normal way: mv /usr/sbin/modem-manager / killall -TERM modem-manager and then run MM like this? MM_SIERRA_APP1_PPP_OK=1 /modem-manager --debug and attempt a connection? Older Sierra devices allow PPP on the APP1 port (ttyUSB4 on your device) but unfortunately we have to whitelist that. It's actually impossible to test which tty accepts PPP on most Sierra devices, so we really have no idea. For examply, my C885 and USB306 allow it, but none of my (four) 8775s or my 8781 allows it. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH] modem: use +CEREG to determine EPS network registration status
On Fri, 2013-02-15 at 09:20 -0800, Ben Chan wrote: > Thanks Aleksander. > > > I committed a a patch to the Chromium OS tree to enable EPS > registration check for the novatel-lte plugin. I'd like to see if you > and Dan would like to enable it for any LTE-capable modem by default. > If so, I will submit a follow-up patch to the modem code instead of > the novatel-lte plugin. Yeah, I'd like to see it enabled by default if the modem has LTE capability and an AT port. Dan > > Ben > > On Thu, Feb 14, 2013 at 11:56 PM, Aleksander Morgado > wrote: > > >>> > >>> > >>> Will you be able to test my patch v2 on some of the modems > you > >>> mentioned? > >> > >> Sure, can do. > > > > The V2 patch doesn't seem to cause problems with the ADU960, > but then > > again, I don't have access to the LTE networks it can use > (AT&T and > > Lightsquared). After patching the code to unconditionally > enable CEREG, > > the device responds correctly to CEREG requests: > > > > AT+CEREG=2 > > OK > > AT+CEREG? > > +CEREG: 2,1 > > OK > > > > when I'm registered on T-Mobile's GSM network. So while I'd > really like > > to have us try CEREG unconditionally if we can, I'm fine > with the V2 > > patch as it is. > > > > I just pushed the v2 patch now. Whenever we can test it > properly I guess > we can enable this by default, so not a big deal. > > Ben, will you send a patch to enable it in the novatel-lte > plugin? > > -- > Aleksander > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: v1.0.8 & DUID
On Fri, 2013-02-15 at 14:32 -0500, Gene Czarcinski wrote: > Although there is a v1.0.8 tag in the NM git, there is still hope since > there has not been a Release Announcement yet. Hmm, I don't see a 1.0.8 or a 1.0.2. The latest release was 0.9.6.4, and the next release will be 0.9.8. This next release will be from this branch: http://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=nm-0-9-8 > I would like to encourage the inclusion of two patches into v1.0.2 > before it ships: > > commit c0efef8c92aecb23df7dcbf3670236719d097873 > dhcp: add special machine-id parse functio > > commit 1b1b4bd91c29425c25e8e979cd77b7a67deb9bf5 > dhcp: write DUID out to lease file if not already present I actually pushed these to that branch and master yesterday after testing those patches and ensuring that my modifications to them were correct. Dan > Without these the DUID support just does not work. > > And, speak of DUID ... I am planning to write a small utility program to > help with DUIDs. It would output two lines. The first line with be the > default-duid in "dhclient format" and the second with be the hex-string > equivalent for use with libvirt and dnsmasq. By default, it would > generate DUID-UUID based on the machine-id. Optionally it would product > DUID-LL and DUID-LLT format when the MAC is provided. > > I am going to do this for myself but is there interest in including such > a utility in the NM package? > > Gene > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > https://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
v1.0.8 & DUID
Although there is a v1.0.8 tag in the NM git, there is still hope since there has not been a Release Announcement yet. I would like to encourage the inclusion of two patches into v1.0.2 before it ships: commit c0efef8c92aecb23df7dcbf3670236719d097873 dhcp: add special machine-id parse functio commit 1b1b4bd91c29425c25e8e979cd77b7a67deb9bf5 dhcp: write DUID out to lease file if not already present Without these the DUID support just does not work. And, speak of DUID ... I am planning to write a small utility program to help with DUIDs. It would output two lines. The first line with be the default-duid in "dhclient format" and the second with be the hex-string equivalent for use with libvirt and dnsmasq. By default, it would generate DUID-UUID based on the machine-id. Optionally it would product DUID-LL and DUID-LLT format when the MAC is provided. I am going to do this for myself but is there interest in including such a utility in the NM package? Gene ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 2/2] novatel-lte: skip soft reset if modem is newly plugged in
I was also wondering if that's needed. I guess soft-resetting the modem
helps clear any unknown settings on the modem before ModemManager starts
managing it. For a hotplugged modem, I'd assume it is managed by
ModemManager from the beginning and have the right settings set.
But if you think it's better/safer to soft reset the modem after
disabling/re-enabling it, we can reset the hotplugged value.
- Ben
On Fri, Feb 15, 2013 at 1:21 AM, Aleksander Morgado
wrote:
> Hey Ben,
>
> Some thoughts about this patch (which is already merged).
>
> On 01/18/2013 08:11 AM, Ben Chan wrote:
> > +static void
> > +modem_init (MMIfaceModem *self,
> > +GAsyncReadyCallback callback,
> > +gpointer user_data)
> > +{
> > +MMAtSerialPort *primary;
> > +GSimpleAsyncResult *result;
> > +guint init_sequence_index;
> > +
> > +result = g_simple_async_result_new (G_OBJECT (self),
> > +callback,
> > +user_data,
> > +modem_init);
> > +
> > +primary = mm_base_modem_peek_port_primary (MM_BASE_MODEM (self));
> > +if (!primary) {
> > +g_simple_async_result_set_error (
> > +result,
> > +MM_CORE_ERROR,
> > +MM_CORE_ERROR_FAILED,
> > +"Need primary AT port to run modem init sequence");
> > +g_simple_async_result_complete_in_idle (result);
> > +g_object_unref (result);
> > +return;
> > +}
> > +
> > +/* Skip ATZ if the device was hotplugged. */
> > +init_sequence_index = mm_base_modem_get_hotplugged (MM_BASE_MODEM
> (self)) ? 1 : 0;
> > +
> > +mm_base_modem_at_sequence_full (MM_BASE_MODEM (self),
> > +primary,
> > +
> &modem_init_sequence[init_sequence_index],
> > +NULL, /*
> response_processor_context */
> > +NULL, /*
> response_processor_context_free */
> > +NULL, /* cancellable */
> > +
> (GAsyncReadyCallback)modem_init_sequence_ready,
> > +result);
>
> Just wondering, shouldn't you reset the 'hotplugged' property in the
> base modem as soon as you check it the first time? If it's left set to
> TRUE, ATZ will not be sent after disabling and re-enabling the modem.
>
> --
> Aleksander
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH] modem: use +CEREG to determine EPS network registration status
Thanks Aleksander. I committed a a patch to the Chromium OS tree to enable EPS registration check for the novatel-lte plugin. I'd like to see if you and Dan would like to enable it for any LTE-capable modem by default. If so, I will submit a follow-up patch to the modem code instead of the novatel-lte plugin. Ben On Thu, Feb 14, 2013 at 11:56 PM, Aleksander Morgado wrote: > > >>> > >>> > >>> Will you be able to test my patch v2 on some of the modems you > >>> mentioned? > >> > >> Sure, can do. > > > > The V2 patch doesn't seem to cause problems with the ADU960, but then > > again, I don't have access to the LTE networks it can use (AT&T and > > Lightsquared). After patching the code to unconditionally enable CEREG, > > the device responds correctly to CEREG requests: > > > > AT+CEREG=2 > > OK > > AT+CEREG? > > +CEREG: 2,1 > > OK > > > > when I'm registered on T-Mobile's GSM network. So while I'd really like > > to have us try CEREG unconditionally if we can, I'm fine with the V2 > > patch as it is. > > > I just pushed the v2 patch now. Whenever we can test it properly I guess > we can enable this by default, so not a big deal. > > Ben, will you send a patch to enable it in the novatel-lte plugin? > > -- > Aleksander > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 2/2] novatel-lte: skip soft reset if modem is newly plugged in
Hey Ben,
Some thoughts about this patch (which is already merged).
On 01/18/2013 08:11 AM, Ben Chan wrote:
> +static void
> +modem_init (MMIfaceModem *self,
> +GAsyncReadyCallback callback,
> +gpointer user_data)
> +{
> +MMAtSerialPort *primary;
> +GSimpleAsyncResult *result;
> +guint init_sequence_index;
> +
> +result = g_simple_async_result_new (G_OBJECT (self),
> +callback,
> +user_data,
> +modem_init);
> +
> +primary = mm_base_modem_peek_port_primary (MM_BASE_MODEM (self));
> +if (!primary) {
> +g_simple_async_result_set_error (
> +result,
> +MM_CORE_ERROR,
> +MM_CORE_ERROR_FAILED,
> +"Need primary AT port to run modem init sequence");
> +g_simple_async_result_complete_in_idle (result);
> +g_object_unref (result);
> +return;
> +}
> +
> +/* Skip ATZ if the device was hotplugged. */
> +init_sequence_index = mm_base_modem_get_hotplugged (MM_BASE_MODEM
> (self)) ? 1 : 0;
> +
> +mm_base_modem_at_sequence_full (MM_BASE_MODEM (self),
> +primary,
> +
> &modem_init_sequence[init_sequence_index],
> +NULL, /* response_processor_context */
> +NULL, /*
> response_processor_context_free */
> +NULL, /* cancellable */
> +
> (GAsyncReadyCallback)modem_init_sequence_ready,
> +result);
Just wondering, shouldn't you reset the 'hotplugged' property in the
base modem as soon as you check it the first time? If it's left set to
TRUE, ATZ will not be sent after disabling and re-enabling the modem.
--
Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Problems with Sierra MC 8790 after kernel upgrade to 3.7.x
I've cleaned up to log, because i have no access to the notebook at the moment. ipv6 should be deactived and is not activated in the config. There is a lot of noise in the log. Could you please disable wifi and wired connections and then attached a compressed version of it? Also, are you trying to use ipv6?: /proc/sys/net/ipv6/conf/ttyUSB3/accept_ra: (4) Datei »/proc/sys/net/ipv6/conf/ttyUSB3/accept_ra« konnte nicht geöffnet werden: No such file or directory sierra_clean.log.gz Description: GNU Zip compressed data ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
