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
next prev parent 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