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
_______________________________________________
ofono mailing list
[email protected]
https://lists.ofono.org/mailman/listinfo/ofono
