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

[Daniel Castelo]

On Wed, May 19, 2010 at 1:47 AM, James Cameron <quozl at laptop.org> wrote:

> 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.
>

The patch was created before that the feature has been backported


> Also, the same changes apply to other wireless network types, not just
> 3G, so I don't think "3G Support" is the right description.
>

Maybe you are right, but the feature has this name:
http://wiki.sugarlabs.org/go/Features/3G_Support



> 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
>
> Backporting this patch to 0.84 is not trivial, i will try.


> > 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.
>

Maybe we have to shown two messages, the error message ("PPP_DISCONNECT")
and a possible solution to the user ("Check the APN configuration.")


>
> 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


I have consult this list. We try to catch just the most common messages.

>
> 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.
>
>
I'd like to know which error messages we should show in each case.

Thanks for your comments/corrections!


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



-- 
Ing. Daniel Castelo
Plan Ceibal - Área Técnica
Avda. Italia 6201
Montevideo - Uruguay.
Tel.: 601.57.73 Interno 2228
E-mail : dcastelo at plan.ceibal.edu.uy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/sugar-devel/attachments/20100519/ee641d58/attachment-0001.htm