Re: [PATCH] ModemManager: Enhancements to Icera error reporting and access technology reporting



According to the documentation I have, the connection state field is '-' when not connected. To quote more specifically:

4) Response to AT%NWSTATE <CR> (execute command)
%NWSTATE: <signal strength>,<MCC/MNC>,<access technology>,<connection state>,<regulation>
. . .
<connection state> possible values:
- for 2G access technologies and 3G access technology when not connected
R99 for 3G access technology when connected
HSDPA for 3G access technology when connected and HSDPA resource allocated by the network
HSUPA for 3G access technology when connected and HSUPA resource allocated by the network
HSDPA-HSUPA for 3G access technology when connected and both HSDPA and HSUPA resources allocated
by the network

I interpret that to mean that if the field is not '-', it indicates the technology that's actually in use for the connection, so that's what should be reported for access technology. If the field is '-', then there's no connection, so we should report what's in the <access technology> field instead.

Also, sorry about missing the g_free() for the result of g_match_info_fetch(). Do you want me to send a new patch, or do you want to take care of it?

Eric

On Thu, Jun 9, 2011 at 5:47 PM, Dan Williams <dcbw redhat com> wrote:
On Tue, 2011-06-07 at 10:35 -0400, Eric Shienbrood wrote:
> Thanks Aleksander! New patch file is attached.

I split these up and pushed all hunks except the hunk for processing the
match info for the NWSTATE response.  Two things there... first you need
to make sure you free the result of g_match_info_fetch() since that's an
allocated string.  Second, what does '-' mean again for the <connected>
field?  I had the docs at some point but I appear to have lost them;
what other values can be there, and why don't we want to update the
access technology when that field is something other than '-'?

Thanks!
Dan

> Eric
>
>
>
> On Tue, Jun 7, 2011 at 2:56 AM, Aleksander Morgado
> <aleksander lanedo com> wrote:
>         Hi Eric,
>
>
>         > The additional error detail allows us to know that a
>         connection failed
>         > because of an invalid APN. Also, when handling access
>         technology
>         > changes, report the technology in use if we're connected.
>         Finally,
>         > avoid using CFUN=0 when disabling the modem.
>
>
>         A small thing to fix in the patch.
>
>         All callbacks receiving a response from the AT serial port
>         should check
>         if the modem has already been removed, so in
>         query_network_error_code_done(), this check is needed just
>         before trying
>         to parse any reply:
>
>            /* If the modem has already been removed, return without
>             * scheduling callback */
>            if (mm_callback_info_check_modem_removed (info))
>                return;
>
>         See
>         http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=9323daec015ecad65c39b6020b62e864c027d858
>
>         Cheers!
>
>         --
>         Aleksander
>
>
>
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]