Re: bluetooth DUN silently discarding "invalid" APNs

[Dan Williams <dcbw redhat com>]

On Fri, 2011-05-06 at 11:02 +0100, Marc Herbert wrote:
> >> 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.
> > 
> 
> No, I was not referring to any default APN stored from the phone, but
> to the case where the phone does not provide any APN to the network *at
> all*.
> 
> Section 3.1 "Definitions" at the very beginning of 3GPP 23.401:
> 
>   Default APN: A Default APN is defined as the APN which is marked as
>   default in the subscription data [...] when no APN is provided by
>   the UE".
> 
> UE = User Equipment. The "subscription data" comes from the HSS in the network.
> 
> In the same spec see also paragraph 12 in section 5.3.2.1. This
> paragraph has about 5-6 sentences starting with: "If the UE does [not]
> provide an APN,..."
> 
> The operator I can connect to using a blank APN did not even exist yet
> when I bought the phone, so for sure the phone is not sneakily
> providing any "good default APN" to get me online. It is a old
> 2.5G EDGE phone by the way.

And T-Mobile appears to allow this as well according to my testing; I
looked around and couldn't find much information on it at all, but
you're right, and we should allow passing no APN to MM, which would
trigger MM to create a blank "default" PDP context with no APN, which MM
would then activate.  Then we hope it works.

Dan