Re: bluetooth DUN silently discarding "invalid" APNs

[Dan Williams <dcbw redhat com>]

On Thu, 2011-05-05 at 09:28 +0100, Marc Herbert wrote:
> Le 04/05/2011 21:02, Dan Williams a écrit :
> 
> > APNs are defined by GSM 03.03 section 14.9 which says:
> >
> > http://www.3gpp.org/ftp/Specs/html-info/0303.htm
> 
> > =====
> > The syntax of the APN shall follow the Name Syntax defined in RFC 2181
> > [14] and RFC 1035 [15]. The APN consists of one or more labels. Each
> > label is coded as one octet length field followed by that number of
> > octets coded as 8 bit ASCII characters. Following RFC 1035 [15] the
> > labels should consist only of the alphabetic characters (A-Z and a-z),
> > digits (0-9) and the dash (-). The case of alphabetic characters is not
> > significant. The APN is not terminated by a length byte of zero.
> > =====
> > 
> 
> It is funny how GSM 03.03 makes the usual misinterpretation of (the
> admittedly confusing) DNS RFC1035, while in the same paragraph quoting
> RFC2181 which explicitly rectifies this misinterpretation (in section
> 11).
> 
> DNS does not put any restrictions on label characters. This
> restriction came from "hostname".
> 
> > But the specification does use the word "should", which implies that
> > APNs may deviate from the suggestion.
> 
> I suspect resolving the APN through DNS is not even mandatory. Some
> networks could use alternative ways to select the GGSN.
> 
> > Many APNs already use '.' (which the specification does not suggest)
> 
> That is because '.' is the usual way to separate DNS labels in text
> form (not on the wire). The '.' is not part of any label.
> 
> > and perhaps we should allow "_" too.
> 
> 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.

Dan