Re: bluetooth DUN silently discarding "invalid" APNs

[Dan Williams <dcbw redhat com>]

On Tue, 2011-05-03 at 12:33 +0100, Marc Herbert wrote:
> Hi,
> 
>   I wasted a number of hours when trying to tether using
> bluetooth... it seems any APN containing an underscore "_" causes the
> DUN configuration entered into the gnome bluetooth wizard to be
> *SILENTLY* discarded.

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

Note that none of the APNs in the  mobile broadband provider database
contain an underscore.

But the specification does use the word "should", which implies that
APNs may deviate from the suggestion.  Many APNs already use '.' (which
the specification does not suggest) and perhaps we should allow "_" too.

> Can anyone reproduce this? Only a bluetooth phone is needed, plus
> deleting the bluetooth configuration for this phone if you already
> have one (sorry), so you can run the wizard on it again. You do not
> even need a valid network subscription to reproduce this problem.
> 
> I am using NetworkManager 0.8.4 in Fedora 14.
> 
> Since the APN is the hostname of the GGSN or PDN gateway, I guess this
> "validation" tries to apply the restrictions of RFC 1123 concerning
> hostnames (note that, as opposed to a common misconception, the DNS
> itself does not have any such restriction, see section 11 in RFC
> 2181. DNS is not just for hostnames.)
> 
> I see extremely little value in this validation. There are millions of
> other and more likely typos that it will never catch. Since it does
> not even issue an error message but silently discard the user input
> instead, the little value that ever was intended is completely
> gone. This validation "feature" has now become a severe bug since it
> hides the next and proper error message (i.e., "connection failed,
> check your settings"). And wastes hours.
> 
> Even worse, wvdial is perfectly able to get me online using an APN
> that includes an underscore. So whatever the standards say, this
> validation prevents some configurations to work.
> 
> By the way it is not possible to enter a blank APN either (asking the
> network use the default APN). This again works perfectly with wvdial.
> And this is valid.

Yes, it's valid, but note that the "default" APN is stored in the
*device*, not the SIM card, and has no relation to the SIM card at all.
So if you ever swap SIM cards, or use a different provider, then the APN
is surely going to be wrong and the dialing will fail.  However, I've
been thinking of ways to enable using the "default" APN since that works
for some phones that don't allow setting the APN at all via AT commands,
but where dialing works fine.

Dan