Open Source Telephony
 help / color / mirror / Atom feed
From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH 2/7] extended support for LTE and NR. Some minor fixes. part 2 of 7
Date: Wed, 19 Sep 2018 13:23:58 -0500	[thread overview]
Message-ID: <99acf5e5-ee78-216b-4651-e9aff31cb839@gmail.com> (raw)
In-Reply-To: <CAKSBH7H+iSZu6OUq56+EAY-kQ3o=fwMDSWTHz49PHBxCq6jHhA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1986 bytes --]

Hi Giacinto,

> I had a look at this all, and I have a problem. I cannot check the 
> parameters as they are entered one by one.
> Example: if I blank user/pwd when the authentication is changed to NONE, 
> then if changed again to CHAP, the module will reject it.
> Shall I store the parameters, or keep them also in case of error?

So in the case of ConnectionContext the parameters are not sent out to 
the driver until context activation is attempted.  Hence all the 
settings are immediate and the activation fails or it succeeds.

However, in the LongTermEvolution driver setup the settings are 
immediate.  Thus the D-Bus API you propose is thus not really suitable 
and needs to be modified. Since we're kind of stuck with the 
'DefaultAccessPointName' property at this point, the only two ways out 
of this I can think of are:

- Have the driver handle this.  So if PAP/CHAP is selected but username 
or password are invalid, default to no authentication.  The assumption 
will be that eventually valid parameters are given.

Or perhaps we only call out into the driver method once the parameters 
in their entirety are valid, accepting whatever the user puts in as long 
as the individual property input is valid according to core validity checks.

....

> 
> Another way would be to have a SetParameters() function, and set them 
> all together, including the APN, and not allowing writing them 
> separately, apart from the APN which already exists.
> I don't really like it, either.
> 

As you point out, this is the second alternative.  AuthenticationMethod, 
Username & Password would need to be set via a method call and 
optionally exposed as [readonly] properties.  Protocol could still be 
handled as per DefaultAccessPointName or inside the aforementioned 
method call.

> Or introduce an atom function that is called before modem->set_online(true)?
> 

This might be trickier, but could also work...

Regards,
-Denis

  reply	other threads:[~2018-09-19 18:23 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-19  5:37 [PATCH 1/7] extended support for LTE and NR. Some minor fixes. part 1 of 7 Giacinto Cifelli
2018-09-19  5:37 ` [PATCH 2/7] extended support for LTE and NR. Some minor fixes. part 2 " Giacinto Cifelli
2018-09-19 15:04   ` Denis Kenzior
2018-09-19 16:07     ` Giacinto Cifelli
2018-09-19 16:30       ` Denis Kenzior
2018-09-19 17:53         ` Giacinto Cifelli
2018-09-19 18:23           ` Denis Kenzior [this message]
2018-09-20  7:57             ` Giacinto Cifelli
2018-09-20 16:02               ` Denis Kenzior
2018-09-20 16:07                 ` Giacinto Cifelli
2018-09-20 16:31                   ` Denis Kenzior
2018-09-20 17:03                     ` Giacinto Cifelli
2018-09-20 17:18                       ` Denis Kenzior
2018-09-20 17:25                         ` Giacinto Cifelli
2018-09-19  5:37 ` [PATCH 3/7] extended support for LTE and NR. Some minor fixes. part 3 " Giacinto Cifelli
2018-09-19 15:05   ` Denis Kenzior
2018-09-19  5:37 ` [PATCH 4/7] extended support for LTE and NR. Some minor fixes. part 4 " Giacinto Cifelli
2018-09-19  5:37 ` [PATCH 5/7] extended support for LTE and NR. Some minor fixes. part 5 " Giacinto Cifelli
2018-09-19  5:37 ` [PATCH 6/7] extended support for LTE and NR. Some minor fixes. part 6 " Giacinto Cifelli
2018-09-19  5:37 ` [PATCH 7/7] extended support for LTE and NR. Some minor fixes. part 7 " Giacinto Cifelli
2018-09-19  8:35 ` [PATCH 1/7] extended support for LTE and NR. Some minor fixes. part 1 " Slava Monich
2018-09-19  9:24   ` Giacinto Cifelli
2018-09-19 15:21     ` Denis Kenzior
2018-09-19 16:28       ` Slava Monich
2018-09-19 16:32         ` Denis Kenzior
2018-09-19 16:54           ` Slava Monich
2018-09-19 16:58             ` Giacinto Cifelli
2018-09-19 20:48             ` Slava Monich
2018-09-19 21:45               ` Denis Kenzior
2018-09-19 23:14                 ` Slava Monich
2018-09-20  2:31                   ` Denis Kenzior
2018-09-19 15:19   ` Denis Kenzior
2018-09-19 14:09 ` Denis Kenzior
2018-09-19 15:42   ` Giacinto Cifelli
2018-09-19 15:59     ` Denis Kenzior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=99acf5e5-ee78-216b-4651-e9aff31cb839@gmail.com \
    --to=denkenz@gmail.com \
    --cc=ofono@ofono.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox