Hi Sergei,
I still cannot understand why ofono does not try to use PAP if the
authentication method is set to CHAP by default (because no method set while
context creation) and it is "obvious" that PAP should be used. pppd does this
BTW, that's why I assumed that it could be "obvious". I am not an expert in this
field. Maybe someone could shed a light on the fact that pppd chooses a correct
authentication method without a problem and ofono does not?
It has been a very long time since we developed PPP (about 10 years now), so my
memory may be fuzzy now. But the answer to your question is that it isn't
possible to auto-detect this.
The issue is, that the 'PPP server' running in the firmware has no clue what the
authentication should be. It is literally taking auth frames from the client
and forwarding them to the network. The network is the one that actually knows
what the authentication details are. 3GPP mandates that CHAP is the 'default'
method for such cases. But seems some providers had legacy software that
demanded PAP, and instead of fixing the backend they pushed all these details
out to the front-end. Hence why you have a need of provisioning data bases like
'mobile-broadband-provider-info' or the android APN db, etc.
So, the LCP configuration stage (where the auth options are chosen) is performed
prior to any of the frames being exchanged between the modem and the network.
You can see this in your log 'ppp_dump_single_port.txt', where gsmdial is
configured for CHAP, NAKs the PAP auth proto and the modem firmware happily
switches to CHAP. Why the subsequent CHALLENGE messages from the modem go
unanswered by gsmdial is not clear to me.
Am I correct that my SW has to know which authentication must be used before it
attempts to activate context for the first time? This is a big inconvenience.
Actually the fact that the context must be activated manually at the first time
is the big inconvenience too for embedded systems. But this is not the biggest
issue for me right now of course.
Unfortunately yes. Look into provisioning contexts automatically. See
plugin/provision.c, plugins/file-provision.c
> Never tried this myself, but I never really had a reason to. Not sure if
there
> is an easy way of doing that given you're running over a MUX. If you come up
> with a nice way, please share.
Sorry, I have not got your point about MUX. I have successfully obtained the
dumps. I have 2 ttyUSB devices and gsmdial works fine with one tty as well as
with both. Could you elaborate a little bit more on the MUX issue?
Didn't you say you have a Quectel device? Some of those are a serial port
based modem and require a multiplexer. I guess you have the USB variant so what
I said doesn't apply.
Please find the dumps attached. I did not find any problems in them. DTE sent a
termination request but why? I tried to use the CHAP, PAP and NONE auth
metnods but NONE hands with gsm dial.
I don't see pppd getting any IPCP protocol going, so I'm not really sure any of
this is working.
I am going to debug ofono as you suggested:
> Maybe put a few debug statements in ppp_auth.c, ppp_pap_start,
ppp_pap_timeout
> and ppp_pap_process_packet. See if PAP even occurs.
Also I have made a small patch for gsmdial that helps to choose auth method.
Please find it attached.
Feel free to send this in using git send-email. I don't review patches in
attachments. Note that the last time I looked at gsmdial was ~9 years ago, so
not sure how up to date it is compared to the ppp based gprs context code in
drivers/atmodem. You may want to use g_at_ppp_set_recording (maybe via
environment variable) from drivers/atmodem/gprs-context.c directly in order to
obtain dumps of what is happening when oFono is attempting to activate the context.
I use cf9e6d048d65ff4a87f5707b0cc4fd3c036d62fb in my patch because the last
commit in master de0d5a19c16bbb3eaba473e0eaaade7f55c48bcb does not build for me
because of goto was left in a function without any label. Please see the error
below and in the file attached:
| ../git/ofono/drivers/gemaltomodem/gprs-context.c: In function
'gemalto_gprs_activate_primary':
| ../git/ofono/drivers/gemaltomodem/gprs-context.c:156:3: error: label 'error'
used but not defined
| goto error;
| ^~~~
Please git pull --rebase. I fixed this several days ago and there have been
other commits applied since.
Maybe I should add some "properties" to context for this modem before
activation? Also I am not happy with the idea that I probably need to set an
authentication method by hand. Could this really be necessary with ofono in some
situations? I added the pppd configuration files of the modem vendor which work
fine. Do I need to add something to the context in ofono before activation?
See above about provisioning.
I strongly believe that ofono as embedded system software has to be as automated
as possible. Do you agree?
Yes, and we try pretty hard to set sane defaults and auto-configure whenever we
can. But in some cases there are constraints we can't work around.
Regards,
-Denis
_______________________________________________
ofono mailing list -- [email protected]
To unsubscribe send an email to [email protected]
