Re: bluetooth DUN silently discarding "invalid" APNs

[Dan Williams <dcbw redhat com>]

On Thu, 2011-05-05 at 17:54 +0100, Marc Herbert wrote:
> >> You should simply just stay clear of this whole mess and not validate
> >> anything. This would add two new and incredibly great features:
> >>
> >> - Restore an error message in case of a typo (as opposed to silently
> >>   discarding user input)
> >> - Support APNs with unusual characters.
> >>
> >> Two new features by merely deleting some code, how great value is that?
> > 
> > The code was put into NM in the first place to ensure that characters
> > like spaces and such that certainly *aren't* allowed in APNs weren't
> > used.  The validation is still necessary, but I think the core problem
> > we should fix is ensuring that you can't type invalid characters into
> > the box and you can't type an invalid APN length.  Then we should extend
> > the allowed characters.  We certainly shouldn't remove the checks
> > completely, since there *are* actually restrictions on the APN contents
> > and length.
> 
> Besides the "hostname" legacy, please tell where do these "certainly
> not allowed" characters come from. My Nokia phone lets me input any
> character crap in the APN field without even a warning. Then I just
> get the same "Connection failed, check your settings" error message
> than for any other "valid" typo  (reminder: Nokia and Ericsson
> designed and implemented GSM, UMTS & LTE practically alone). wvdial
> lets me enter the same crap. So why is NetworkManager implementing
> this? Too much spare time?

Because certain characters are not allowed, and the length is
restricted, and just because you have devices that might for some reason
allow this, there are devices that certainly don't, and these characters
are not valid at all anyway.  So to avoid unexpected errors *before* the
connect attempt, we should be filtering them out.  We don't allow spaces
in IP addresses, so why should we allow in APNs where they are also
invalid?  It's basic input validation.

Yes, we'll allow _.  But no, we're not going to allow ȫ.  Why?  Because
the standards disallow that.  APNs are not a freeform byte-string type.
Nor should we treat them as such.

The original reason that the validation code was added was specifically
for spaces.  These cause some modems to puke, not to mention that
causing the connect attempt to fail because there's a space in the APN
or something like that is completely unhelpful, when we know that these
characters are invalid.

Dan

> But once again, the core problem is not abusive validation. The core
> problem is silently discarding user input with a misleading
> "configuration completed" message. This needs an quick fix that cannot
> wait the redesign of a better user interface. And surprise, there is a
> really obvious quick fix: just behave like Nokia.
> 
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list