Hi Denis, Thank you for your reply. I still cannot activate the context neither with ofono nor with gsmdial but pppd does this fine. But, I have not tested pppd with CHAP, I think it is impossible. I was getting the error below when I tried: root@131D2F4C5254324B:/mnt/data# pppd call quectel-ppp & [1] 18583 root@131D2F4C5254324B:/mnt/data# pppd: The remote system (3gppp) is required to authenticate itself pppd: but I couldn't find any suitable secret (password) for it to use to do so. ^C [1]+ Done(1) pppd call quectel-ppp 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? 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. there come up 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? 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 am going to debug ofono as you suggested: ppp_pap_timeout Also I have made a small patch for gsmdial that helps to choose auth method. Please find it attached. 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; | ^~~~ 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? I strongly believe that ofono as embedded system software has to be as automated as possible. Do you agree? Any suggestions will be appreciated. I really stuck with this. I do not want to stop using ofono because of the new modem. Yours sincerely, Sergei Golubtsov. On Wed, Dec 30, 2020 at 5:51 PM Denis Kenzior <denkenz(a)gmail.com&gt; wrote: > Hi Sergei, > > On 12/30/20 4:00 AM, Sergei Golubtsov wrote: > > Hello Denis, > > > > > Are the username and password set properly on the context? > > > > Yes, they are. > > root@131D2F4C5254324B:~# /usr/lib/ofono/test/list-contexts > > [ /quectel_0 ] > > [ /quectel_0/context1 ] > > Name = Россия > > Active = 0 > > Type = internet > > Protocol = ip > > AccessPointName = internet > > Username = gdata > > Password = gdata > > AuthenticationMethod = pap > > Settings = { } > > IPv6.Settings = { } > > > > [ /quectel_0/context2 ] > > Name = МегаФон MMS > > Active = 0 > > Type = mms > > Protocol = ip > > AccessPointName = mms > > Username = mms > > Password = mms > > AuthenticationMethod = pap > > MessageProxy = 10.10.10.10:8080 <http://10.10.10.10:8080> > > MessageCenter = http://mmsc:8002 > > Settings = { } > > IPv6.Settings = { } > > > > > > > And you may want to share the log of oFono activating the context > configured > > for PAP. > > > > I have added the PAP context activation log file from ofono to > this email as > > well as I did in the previous email. Please find it attached. It also > fails at > > It wasn't clear whether the previous log was pap or chap. With chap the > PPP > implementation would stop and wait for the chap challenge. So if that > never > comes, that would explain why you get stuck just after entering phase '2' > -> > PHASE_AUTHENTICATION > > > the same phase: "gatppp.c:ppp_enter_phase() 2" > > Probably I need to try to dump the ppp connection and analyze it with > WireShark. > > Any ideas will be appreciated. > > there > is an easy way of doing that given you're running over a MUX. If you come > up > > ppp_pap_timeout > > Regards, > -Denis >

Hi Denis, Thank you very much for your explanation. That was very helpful. My previous dumps from pppd were incomplete somehow. I have got a new dump from pppd using CHAP. Please find it attached. The dump looks good. I did that a bit differently. I have added some DBG () prints to gathdlc.c because the problem has been found there. Data that modem sends in phase 2 is not decoded properly and as a result ppp_receive () never invoked. I am not sure why because I do not have any info about the algorithm and encoding. Could you please advise me on this? I have attached a log from ofono with data dumping in new_bytes () and a small patch for the gathdlc.c file that I used to obtain this log. The log gives a clear picture but I cannot understand why pppd works in this situation and ofono does not? Is it an ofono problem? Is there any documentation about the decoding process implemented in the new_bytes () ofono function? Any help will be appreciated. Best regards, Sergei.

Hi Denis, I have found the problem. ofono does not apply ACCM, which is proposed by the DCE in a configuration request. The EC200 Quectel modem uses ACCM = 0x00000000 in the authentication phase and ofono ACK such configuration but does not apply configuration options. That is why ofono silently drops some frames from the DCE in phase 2 and does not answer to packets because the FCS (CRC) of packets does not match the value calculated by ofono. I have sent a patch, which solves the problem. I am concerned about two things: 1. Did I choose the right place to insert the configuration options application code? 2. ACCM is for asynchronous links only. Does ofono support other links? If so we must check the link type before applying the ACCM configuration option as suggested in RFC 1812 <https://www.freesoft.org/CIE/RFC/1812/index.htm> 3.3.5.2. Regards, Sergei.

Hi Denis, Happy New Year. Apologies for the late response, I was in holiday mode. Happy New Year too. Thank you for your helpful answer. So far, all modems on this planet have honored the default properly... Sorry for my misunderstanding. I should have read the RFC better but this aspect is defined properly only in the following clause - "The Configuration Option is used to inform the peer which control characters MUST remain mapped when the peer sends them." So I have managed to find this after your message. Thank you. - Override the negotiated ACCM (using g_at_hdlc_set_recv_accm for your I think that this modem is buggy as you have clearly shown. I agree that it is not a good idea to do something which does not follow the RFCs fine. But, I feel that the default value for ACCM is not that one we should use. Excuse me if I am too direct here, I am not an expert in this field but I think it is better for DTE to send a configuration request with ACCM = 0x00000000 as pppd does because this allows us to send more information in the same number of bytes. Would you agree? If not I will override the negotiated ACCM, if it is left default, for this chinese modem because I do not feel that they could update the firmware to fulfill the RFC requirements in a reasonable amount of time if they even would. I do not think that they would even find this necessary if I had told them. Thank you very much for your help and sorry for bad patches. I will fix them soon. Have a great day. Regards, Sergei.