Re: DUN silently discarding "invalid" APNs

[Dan Williams <dcbw redhat com>]

On Fri, 2011-06-03 at 11:15 +0100, Marc Herbert wrote:
> By the way I found out that this APN validation problem is not
> specific to bluetooth. I fixed the subject accordingly.
> 
> 
> Le 05/05/2011 18:17, Dan Williams a écrit :
> > We don't allow spaces in IP addresses,...
> 
> I do not see what this has to do with anything.
> 
> 
> > 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,
> 
> It is helpful, because it provides a consistent user interface:
> 
>    APN typo => connection error message, always
> 
> For sure end users do not care getting different feedback depending if
> their APN typos are valid according to RFC 123, GSM 456 or 3GPP 789.
> 
> 
> >  It's basic input validation.
> 
> This sentence is genuine handwaving.
> 
> Considering that:
> 
> - The GSM spec is merely quoting a common misinterpretation of the
>   DNS specs.
> - Even if usual, it's not even sure that DNS is mandatory to resolve
>   an APN.
> - I can get on-line with supposedly "forbidden" characters.
> - These supposedly forbidden characters are not defined in any other
>   spec than the misinterpretation above.
> - You are still not sure which characters should be allowed.
> - The only sound rationale mentioned so far is: prevent a very small
>   number of lusers from crashing a small number of modem models.
> - My Nokia Series 40 accepts any character.
> - My Nokia Series 60 (Symbian) accepts any character.
> - wvdial accepts any character.
> - NetworkManager seems to be the only guy implementing any
>   kind of APN validation.
> - NM does not (yet) support blank APNs
> 
> ... then it is clear that this made up APN validation problem is
> anything but "basic".
> 
> If you really want to be more restrictive than Nokia for some reasons
> then please at least specify and document your restrictions clearly,
> I mean not like "let's forbid this character because it is 'certainly'
> invalid". Examples:
> - Same restrictions as the "hostname" command (= the usual, very
>   restrictive DNS misinterpretation)
> - No spaces as workarounds for well known modem bugs.
> - DNS maximum size
> - other?

Those are all valid things to do.  But at this point I'm not going to
add support for more characters until we get reports of APNs that use
them in the wild, like you reported one that uses _.  I believe that's
the right thing to do to minimize potential breakage due to shitty modem
firmware and backend systems, yet still allow changes going forward.

Dan

> And of course, a validation error message that does not say
> "Success" (did I mention this already?)
> 
> Cheers,
> 
> Marc
> 
> 
> 
> 
> 
> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list