Re: bluetooth DUN silently discarding "invalid" APNs
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 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
>> 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. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
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 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
>> 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? 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
Re: bluetooth DUN silently discarding "invalid" APNs
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 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
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? Cheers, Marc ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
Le 04/05/2011 21:02, Dan Williams a écrit : > 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: Dan, You did not address at all the most important issue: whether the validation is good or not, it should not SILENTLY discard user input. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
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 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
