[Sugar-devel] 3G Support: show connection errors- Patch 1759

[James Cameron]

On Tue, May 18, 2010 at 04:26:44PM -0300, Daniel Castelo wrote:
> I have this ticket pending, could you give your feedback? Thanks!!!
> http://bugs.sugarlabs.org/ticket/1759
> 
> This patch improves the feature 3G Support (added in 0.88).

It was also backported to 0.84, so the mention of 0.88 is probably
unnecessarily restrictive.
 
Also, the same changes apply to other wireless network types, not just
3G, so I don't think "3G Support" is the right description.

By the way, if you produce a 0.84 re-spin, then I can easily test it for
you.  See sucrose-0.84 branch in
git://git.sugarlabs.org/sugar/mainline.git

> Includes:
> Show the connection errors
> Apply Eben's Mockup:  http://wiki.sugarlabs.org/go/File:3G_device.png
> 
> 
> ---
> index 94a4293..995446c 100644
> --- a/extensions/deviceicon/network.py
> +++ b/extensions/deviceicon/network.py
> @@ -267,35 +282,89 @@ class GsmPalette(Palette):

...

> +    def _get_error_by_nm_reason(self, reason):
> +        if reason in [network.NM_DEVICE_STATE_REASON_NO_SECRETS,
> network.NM_DEVICE_STATE_REASON_GSM_PIN_CHECK_FAILED]:
> +            message = _('The Pin/Puk configuration is not valid.')

There can be other explanations for this reason, such as incorrect SIM
inserted.  It is better to stick to the meaning; "PIN check failed."

> +        elif reason in [network.NM_DEVICE_STATE_REASON_PPP_DISCONNECT,
> network.NM_DEVICE_STATE_REASON_PPP_FAILED]:
> +            message = _('Check the APN configuration.')

While APN is indeed known to cause PPP_DISCONNECT and PPP_FAILED, there
are many other reasons, and so it is incorrect to specifically identify
APN as the only cause.  An invalid APN is a common cause, but not the
only cause.  Another cause commonly seen is lack of radio signal or
antenna.

Also, "Access Point Name (APN)" is how it is described in the Modem
Configuration control panel, and so that is how you should describe it
in a message.

> +        elif reason in [network.NM_DEVICE_STATE_REASON_MODEM_NO_CARRIER]:
> +            message = _('Check the tel number configuration.')

Again, this is not the only reason this can occur.

Also, "tel number" is not the way it is described in the control panel,
it uses "Number".

> +        elif reason in [network.NM_DEVICE_STATE_REASON_MODEM_DIAL_TIMEOUT]:
> +            message = _('Time out. Check the tel configuration')

"tel number" should be "Number".

> +        else:
> +            message = _('Unexpected error.')

More should be handled.

> +        return message
> +   
>      def __toggle_state_cb(self, menuitem):
>          if self._current_state == _GSM_STATE_NOT_READY:
>              pass

...

> index 3a949da..579ed8d 100644
> --- a/src/jarabe/model/network.py
> +++ b/src/jarabe/model/network.py
> @@ -54,6 +54,13 @@ NM_ACTIVE_CONNECTION_STATE_UNKNOWN = 0
>  NM_ACTIVE_CONNECTION_STATE_ACTIVATING = 1
>  NM_ACTIVE_CONNECTION_STATE_ACTIVATED = 2
>  
> +NM_DEVICE_STATE_REASON_NO_SECRETS = 7
> +NM_DEVICE_STATE_REASON_PPP_DISCONNECT = 13
> +NM_DEVICE_STATE_REASON_PPP_FAILED = 14
> +NM_DEVICE_STATE_REASON_MODEM_NO_CARRIER = 25
> +NM_DEVICE_STATE_REASON_MODEM_DIAL_TIMEOUT = 26
> +NM_DEVICE_STATE_REASON_GSM_PIN_CHECK_FAILED = 34

You seem to have selected a subset of available NM_DEVICE_STATE_REASON
values.  A larger list is at

http://projects.gnome.org/NetworkManager/developers/spec.html

and shows several reasons that an Australian deployment would expect to
encounter with the Australian wireless broadband provider networks.

I think more reasons should be handled.

-- 
James Cameron
http://quozl.linux.org.au/