Re: [PATCH 1/6] lte-api: protocol and authentication properties
Hi Denis, On Fri, Oct 12, 2018 at 6:06 AM Denis Kenzior wrote: > > Hi Giacinto, > > >> Reading through your patches, I'm missing an overarching explanation of > >> why we need this. Do you really have an LTE network in range that > >> requires authentication for the default APN? > > > > yes, quite a few of them actually. > > And all private APN I have seen so far require authentication, even > > for the combined attach. > > > > Are these networks something a typical user would see? Or is this > mainly for M2M type usecases? My focus is mainly M2M use cases, but also public networks may require authentication. > > Fundamentally this whole username / password for a default bearer > activation is utterly insane. The network provider has your IMSI, it > can lookup whether you're authorized for that APN or not, or suggest you > an APN that will work... But I digress.. There is also another problem: the default and data context APN is often the same, and if the auth is not set for both in the same way, the context activation fails. But I digress too. > > > > > Shall I extend the explanation? > > An extended explanation is always a good idea. Especially for something > that seems to be pretty esoteric. > > > There wasn't much of an explanation why we need a default APN for LTE, > > either. > > > > Sure there was. Not sure why you say that :) Maybe it wasn't recorded > in the git commit but it was discussed on the mailing list, IRC, etc. > But again, see above. The whole default attach APN needing to be > provisioned by the client is utterly insane. I prefer not to comment on these practices. For instance, is there an archive of the chat and mailing list that I or anyone could access? > > Regards, > -Denis Regards, Giacinto ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
Re: [PATCH 1/6] lte-api: protocol and authentication properties
Hi Giacinto, Reading through your patches, I'm missing an overarching explanation of why we need this. Do you really have an LTE network in range that requires authentication for the default APN? yes, quite a few of them actually. And all private APN I have seen so far require authentication, even for the combined attach. Are these networks something a typical user would see? Or is this mainly for M2M type usecases? Fundamentally this whole username / password for a default bearer activation is utterly insane. The network provider has your IMSI, it can lookup whether you're authorized for that APN or not, or suggest you an APN that will work... But I digress.. Shall I extend the explanation? An extended explanation is always a good idea. Especially for something that seems to be pretty esoteric. There wasn't much of an explanation why we need a default APN for LTE, either. Sure there was. Not sure why you say that :) Maybe it wasn't recorded in the git commit but it was discussed on the mailing list, IRC, etc. But again, see above. The whole default attach APN needing to be provisioned by the client is utterly insane. Regards, -Denis ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
Re: [PATCH 1/6] lte-api: protocol and authentication properties
Hi Jonas, On Thu, Oct 11, 2018 at 9:07 PM Jonas Bonn wrote: > > Hi Giacinto, > > Reading through your patches, I'm missing an overarching explanation of > why we need this. Do you really have an LTE network in range that > requires authentication for the default APN? yes, quite a few of them actually. And all private APN I have seen so far require authentication, even for the combined attach. > What happens if > authentication fails... are you connected to an alternative APN > automatically, with other service parameters? What indication is > available to the user if authentication fails? In general LTE registration is denied and fallback to legacy technology if available. > > /Jonas Shall I extend the explanation? There wasn't much of an explanation why we need a default APN for LTE, either. Regards, Giacinto > > > On 10/10/18 08:54, Giacinto Cifelli wrote: > > added 4 properties for handling the type of context and the > > authentication method, exactly like in any gprs context handling. > > The properties are named after the equivalent gprs-context one, for > > compatibility and uniformity. > > --- > > doc/lte-api.txt | 34 ++ > > 1 file changed, 34 insertions(+) > > > > diff --git a/doc/lte-api.txt b/doc/lte-api.txt > > index 8a2a97d9..e9cbba0a 100644 > > --- a/doc/lte-api.txt > > +++ b/doc/lte-api.txt > > @@ -33,3 +33,37 @@ Properties string DefaultAccessPointName [readwrite] > > > > Setting this property to an empty string clears the > > default APN from the modem. > > + > > + string Protocol [readwrite] > > + > > + Holds the protocol for this context. Valid values > > + are: "ip", "ipv6" and "dual". Default value is "ip". > > + > > + string AuthenticationMethod [readwrite] > > + > > + Sets the Method used for the authentication > > + for the default APN. > > + > > + Available values are "none", "pap" and "chap". > > + Default is "none". > > + > > + If the AuthenticationMethod is set to 'none' it remove > > + the authentication for the DefaultAPN. > > + In case of AuthenticationMethod 'none', > > + if the Username and Password properties are not empty, > > + the values are preserved in the properties, but they > > + are not used or transmitted to the module. > > + Conversely, if Username or Password are empty, the > > + authentication method selected internally is 'none', > > + but the property AuthenticationMethod is left > > unchanged. > > + > > + string Username [readwrite] > > + > > + Holds the username to be used for authentication > > + purposes. > > + > > + string Password [readwrite] > > + > > + Holds the password to be used for authentication > > + purposes. > > + > ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
Re: [PATCH 1/6] lte-api: protocol and authentication properties
Hi Giacinto, Reading through your patches, I'm missing an overarching explanation of why we need this. Do you really have an LTE network in range that requires authentication for the default APN? What happens if authentication fails... are you connected to an alternative APN automatically, with other service parameters? What indication is available to the user if authentication fails? /Jonas On 10/10/18 08:54, Giacinto Cifelli wrote: added 4 properties for handling the type of context and the authentication method, exactly like in any gprs context handling. The properties are named after the equivalent gprs-context one, for compatibility and uniformity. --- doc/lte-api.txt | 34 ++ 1 file changed, 34 insertions(+) diff --git a/doc/lte-api.txt b/doc/lte-api.txt index 8a2a97d9..e9cbba0a 100644 --- a/doc/lte-api.txt +++ b/doc/lte-api.txt @@ -33,3 +33,37 @@ Properties string DefaultAccessPointName [readwrite] Setting this property to an empty string clears the default APN from the modem. + + string Protocol [readwrite] + + Holds the protocol for this context. Valid values + are: "ip", "ipv6" and "dual". Default value is "ip". + + string AuthenticationMethod [readwrite] + + Sets the Method used for the authentication + for the default APN. + + Available values are "none", "pap" and "chap". + Default is "none". + + If the AuthenticationMethod is set to 'none' it remove + the authentication for the DefaultAPN. + In case of AuthenticationMethod 'none', + if the Username and Password properties are not empty, + the values are preserved in the properties, but they + are not used or transmitted to the module. + Conversely, if Username or Password are empty, the + authentication method selected internally is 'none', + but the property AuthenticationMethod is left unchanged. + + string Username [readwrite] + + Holds the username to be used for authentication + purposes. + + string Password [readwrite] + + Holds the password to be used for authentication + purposes. + ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
[PATCH 1/6] lte-api: protocol and authentication properties
added 4 properties for handling the type of context and the authentication method, exactly like in any gprs context handling. The properties are named after the equivalent gprs-context one, for compatibility and uniformity. --- doc/lte-api.txt | 34 ++ 1 file changed, 34 insertions(+) diff --git a/doc/lte-api.txt b/doc/lte-api.txt index 8a2a97d9..e9cbba0a 100644 --- a/doc/lte-api.txt +++ b/doc/lte-api.txt @@ -33,3 +33,37 @@ Properties string DefaultAccessPointName [readwrite] Setting this property to an empty string clears the default APN from the modem. + + string Protocol [readwrite] + + Holds the protocol for this context. Valid values + are: "ip", "ipv6" and "dual". Default value is "ip". + + string AuthenticationMethod [readwrite] + + Sets the Method used for the authentication + for the default APN. + + Available values are "none", "pap" and "chap". + Default is "none". + + If the AuthenticationMethod is set to 'none' it remove + the authentication for the DefaultAPN. + In case of AuthenticationMethod 'none', + if the Username and Password properties are not empty, + the values are preserved in the properties, but they + are not used or transmitted to the module. + Conversely, if Username or Password are empty, the + authentication method selected internally is 'none', + but the property AuthenticationMethod is left unchanged. + + string Username [readwrite] + + Holds the username to be used for authentication + purposes. + + string Password [readwrite] + + Holds the password to be used for authentication + purposes. + -- 2.17.1 ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
