[MM] [PATCH] modem: use +CEREG to determine EPS network registration status

2013-02-06 Thread Ben Chan
This patch adds the support for solicited/unsolicited EPS network
registration status via AT+CEREG, which is configurable via the
'iface-modem-3gpp-eps-network-supported' property of the
MMIfaceModem3gpp interface and is disabled by default.
---
 src/mm-broadband-modem-qmi.c   |   3 +
 src/mm-broadband-modem.c   | 165 +++--
 src/mm-iface-modem-3gpp.c  |  51 -
 src/mm-iface-modem-3gpp.h  |  10 ++-
 src/mm-modem-helpers.c |  82 +++-
 src/mm-modem-helpers.h |   1 +
 src/tests/test-modem-helpers.c | 121 +++---
 7 files changed, 365 insertions(+), 68 deletions(-)

diff --git a/src/mm-broadband-modem-qmi.c b/src/mm-broadband-modem-qmi.c
index aa82f0e..05be718 100644
--- a/src/mm-broadband-modem-qmi.c
+++ b/src/mm-broadband-modem-qmi.c
@@ -3984,6 +3984,7 @@ static void
 modem_3gpp_run_registration_checks (MMIfaceModem3gpp *self,
 gboolean cs_supported,
 gboolean ps_supported,
+gboolean eps_supported,
 GAsyncReadyCallback callback,
 gpointer user_data)
 {
@@ -4138,6 +4139,7 @@ static void
 modem_3gpp_disable_unsolicited_registration_events (MMIfaceModem3gpp *self,
 gboolean cs_supported,
 gboolean ps_supported,
+gboolean eps_supported,
 GAsyncReadyCallback 
callback,
 gpointer user_data)
 {
@@ -4183,6 +4185,7 @@ static void
 modem_3gpp_enable_unsolicited_registration_events (MMIfaceModem3gpp *self,
gboolean cs_supported,
gboolean ps_supported,
+   gboolean eps_supported,
GAsyncReadyCallback 
callback,
gpointer user_data)
 {
diff --git a/src/mm-broadband-modem.c b/src/mm-broadband-modem.c
index 3778b56..505c42a 100644
--- a/src/mm-broadband-modem.c
+++ b/src/mm-broadband-modem.c
@@ -86,6 +86,7 @@ enum {
 PROP_MODEM_3GPP_REGISTRATION_STATE,
 PROP_MODEM_3GPP_CS_NETWORK_SUPPORTED,
 PROP_MODEM_3GPP_PS_NETWORK_SUPPORTED,
+PROP_MODEM_3GPP_EPS_NETWORK_SUPPORTED,
 PROP_MODEM_CDMA_CDMA1X_REGISTRATION_STATE,
 PROP_MODEM_CDMA_EVDO_REGISTRATION_STATE,
 PROP_MODEM_CDMA_CDMA1X_NETWORK_SUPPORTED,
@@ -129,6 +130,7 @@ struct _MMBroadbandModemPrivate {
 MMModem3gppRegistrationState modem_3gpp_registration_state;
 gboolean modem_3gpp_cs_network_supported;
 gboolean modem_3gpp_ps_network_supported;
+gboolean modem_3gpp_eps_network_supported;
 /* Implementation helpers */
 GPtrArray *modem_3gpp_registration_regex;
 
@@ -3280,6 +3282,7 @@ registration_state_changed (MMAtSerialPort *port,
 gulong lac = 0, cell_id = 0;
 MMModemAccessTechnology act = MM_MODEM_ACCESS_TECHNOLOGY_UNKNOWN;
 gboolean cgreg = FALSE;
+gboolean cereg = FALSE;
 GError *error = NULL;
 
 if (!mm_3gpp_parse_creg_response (match_info,
@@ -3288,6 +3291,7 @@ registration_state_changed (MMAtSerialPort *port,
   &cell_id,
   &act,
   &cgreg,
+  &cereg,
   &error)) {
 mm_warn ("error parsing unsolicited registration: %s",
  error && error->message ? error->message : "(unknown)");
@@ -3298,6 +3302,8 @@ registration_state_changed (MMAtSerialPort *port,
 /* Report new registration state */
 if (cgreg)
 mm_iface_modem_3gpp_update_ps_registration_state (MM_IFACE_MODEM_3GPP 
(self), state);
+else if (cereg)
+mm_iface_modem_3gpp_update_eps_registration_state (MM_IFACE_MODEM_3GPP 
(self), state);
 else
 mm_iface_modem_3gpp_update_cs_registration_state (MM_IFACE_MODEM_3GPP 
(self), state);
 
@@ -3484,12 +3490,16 @@ typedef struct {
 GSimpleAsyncResult *result;
 gboolean cs_supported;
 gboolean ps_supported;
+gboolean eps_supported;
 gboolean run_cs;
 gboolean run_ps;
+gboolean run_eps;
 gboolean running_cs;
 gboolean running_ps;
+gboolean running_eps;
 GError *cs_error;
 GError *ps_error;
+GError *eps_error;
 } RunRegistrationChecksContext;
 
 static void
@@ -3500,6 +3510,8 @@ run_registration_checks_context_complete_and_free 
(RunRegistrationChecksContext
 g_error_free (ctx->cs_error);
 if (ctx->ps_error)
 g_error_free (ctx->ps_error);
+if (ctx->eps_error)
+g_error_free (ctx->eps_error);
 

Re: NetworkManager git20121211

2013-02-06 Thread Gene Czarcinski

On 01/31/2013 04:38 PM, Dan Williams wrote:

And by "virtual networks" you mean bridge interfaces, as I see from the
bug.  Bridging support will be turned off-by-default in the 0.9.8
release until we can become better at cooperating with existing
configurations.  It will be enabled by editing the NetworkManager.conf
file if you'd like to use NM to configure bridges.
I have been following the "discussion on bugzilla 905035 and agree that 
slowly, slowly is a good approach for introducing bridge support in NM.  
Once the support is there and used to some degree (and all the usual 
corner-case "features" dealt with), then integration with other services 
such as libvirt can proceed.


In any case, I will be watching bugzilla for an available update. When 
it is available, I will give it a try.


Gene
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Airplane mode setting not saved after restart

2013-02-06 Thread Dan Williams
On Wed, 2013-02-06 at 16:02 +0200, John G. wrote:
> On Wed, Feb 6, 2013 at 12:46 AM, Dan Williams  wrote:
> > On Tue, 2013-02-05 at 10:44 +0200, John G. wrote:
> >> Hello,
> >>
> >> I rarely use my laptop's wifi, so I enable airplane mode (aka rfkill)
> >> from gnome nm applet to disable it completely (it doesn't have a
> >> hardware switch). The problem is that after every restart this setting
> >> isn't saved. The wifi interface is still down but rfkill is not used
> >> (airplane mode is off). So I have to use the rfkill program with a
> >> startup script. Sometimes when I need wifi, I have to either disable
> >> the startup script or manually enable wifi after every restart.  This
> >> doesn't seem very practical to me. Is this intended or should I open a
> >> bug?
> >
> > There are two settings at play here; rfkill and NM on/off.  rfkill may
> > or may not be present, and may or may not be saved over restart, since
> > it's a hardware/bios thing that we can't control.
> >
> > Thus NM has a wifi on/off toggle as well, which *is* preserved over
> > restarts.  This gets toggled when you flip the switch, and NM will also
> > flip the hardware rfkill if available to ensure the radio is dead.  This
> > value should always follow what you have told NM either through the
> > applet or through "nmcli nm wifi on/off", and again, is different than
> > hardware rfkill.
> >
> > It seems like there's something we need to debug further, since the
> > value should be getting saved
> > to /var/lib/NetworkManager/NetworkManager.state.  Does that file exist
> > for you and if so, what's in it after you flip the switch?
> >
> > Dan
> >
> 
> The wifi state is properly saved in NetworkManager.state and restored
> after restart but not the software-rfkill one. All I am saying is that
> it would make sense to store the soft-rfkill state aswell and restore
> it on startup.

Right you are.  I think it does make sense to ensure the kernel rfkill
state is synced with NM state when NM starts, since the NM state is
always specified by the user.  This also keeps startup behavior
consistent with NM wireless on/off behavior after startup.

I've pushed a patch that makes this happen.

Thanks!
Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: [PATCH] modem-manager: plug memleak

2013-02-06 Thread Dan Williams
On Wed, 2013-02-06 at 18:38 +0100, Aleksander Morgado wrote:
> ---
>  src/modem-manager/nm-modem-manager.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)

Pushed, thanks!

Dan

> diff --git a/src/modem-manager/nm-modem-manager.c 
> b/src/modem-manager/nm-modem-manager.c
> index d896b46..553c114 100644
> --- a/src/modem-manager/nm-modem-manager.c
> +++ b/src/modem-manager/nm-modem-manager.c
> @@ -511,19 +511,23 @@ modem_manager_1_name_owner_changed (MMManager 
> *modem_manager_1,
>  GParamSpec *pspec,
>  NMModemManager *self)
>  {
> + gchar *name_owner;
> +
>   /* Quit poking, if any */
>   if (self->priv->modem_manager_1_poke_id) {
>   g_source_remove (self->priv->modem_manager_1_poke_id);
>   self->priv->modem_manager_1_poke_id = 0;
>   }
>  
> - if (!g_dbus_object_manager_client_get_name_owner 
> (G_DBUS_OBJECT_MANAGER_CLIENT (modem_manager_1))) {
> + name_owner = g_dbus_object_manager_client_get_name_owner 
> (G_DBUS_OBJECT_MANAGER_CLIENT (modem_manager_1));
> + if (!name_owner) {
>   nm_log_info (LOGD_MB, "ModemManager disappeared from bus");
>   schedule_modem_manager_1_relaunch (self, 0);
>   return;
>   }
>  
>   /* Available! */
> + g_free (name_owner);
>   modem_manager_1_available (self);
>  }
>  


___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


[PATCH] modem-manager: plug memleak

2013-02-06 Thread Aleksander Morgado
---
 src/modem-manager/nm-modem-manager.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/modem-manager/nm-modem-manager.c 
b/src/modem-manager/nm-modem-manager.c
index d896b46..553c114 100644
--- a/src/modem-manager/nm-modem-manager.c
+++ b/src/modem-manager/nm-modem-manager.c
@@ -511,19 +511,23 @@ modem_manager_1_name_owner_changed (MMManager 
*modem_manager_1,
 GParamSpec *pspec,
 NMModemManager *self)
 {
+   gchar *name_owner;
+
/* Quit poking, if any */
if (self->priv->modem_manager_1_poke_id) {
g_source_remove (self->priv->modem_manager_1_poke_id);
self->priv->modem_manager_1_poke_id = 0;
}
 
-   if (!g_dbus_object_manager_client_get_name_owner 
(G_DBUS_OBJECT_MANAGER_CLIENT (modem_manager_1))) {
+   name_owner = g_dbus_object_manager_client_get_name_owner 
(G_DBUS_OBJECT_MANAGER_CLIENT (modem_manager_1));
+   if (!name_owner) {
nm_log_info (LOGD_MB, "ModemManager disappeared from bus");
schedule_modem_manager_1_relaunch (self, 0);
return;
}
 
/* Available! */
+   g_free (name_owner);
modem_manager_1_available (self);
 }
 
-- 
1.8.1

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: Airplane mode setting not saved after restart

2013-02-06 Thread John G.
On Wed, Feb 6, 2013 at 12:46 AM, Dan Williams  wrote:
> On Tue, 2013-02-05 at 10:44 +0200, John G. wrote:
>> Hello,
>>
>> I rarely use my laptop's wifi, so I enable airplane mode (aka rfkill)
>> from gnome nm applet to disable it completely (it doesn't have a
>> hardware switch). The problem is that after every restart this setting
>> isn't saved. The wifi interface is still down but rfkill is not used
>> (airplane mode is off). So I have to use the rfkill program with a
>> startup script. Sometimes when I need wifi, I have to either disable
>> the startup script or manually enable wifi after every restart.  This
>> doesn't seem very practical to me. Is this intended or should I open a
>> bug?
>
> There are two settings at play here; rfkill and NM on/off.  rfkill may
> or may not be present, and may or may not be saved over restart, since
> it's a hardware/bios thing that we can't control.
>
> Thus NM has a wifi on/off toggle as well, which *is* preserved over
> restarts.  This gets toggled when you flip the switch, and NM will also
> flip the hardware rfkill if available to ensure the radio is dead.  This
> value should always follow what you have told NM either through the
> applet or through "nmcli nm wifi on/off", and again, is different than
> hardware rfkill.
>
> It seems like there's something we need to debug further, since the
> value should be getting saved
> to /var/lib/NetworkManager/NetworkManager.state.  Does that file exist
> for you and if so, what's in it after you flip the switch?
>
> Dan
>

The wifi state is properly saved in NetworkManager.state and restored
after restart but not the software-rfkill one. All I am saying is that
it would make sense to store the soft-rfkill state aswell and restore
it on startup.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list