Hi Sergei,

On 1/2/21 3:52 AM, Sergei Golubtsov wrote:
> Hi Denis,
> 

Happy New Year.  Apologies for the late response, I was in holiday mode.

>     The log from my previous message clearly shows that the problem is that the
>     modem stopped escaping control characters (<0x20) with 0x7d when phase 2 had
>     begun. Apparently pppd is ok with this behaviour. Am going to compare the
>     HLDC frame parsers in pppd and ofono. Is it a modem bug or an ofono missing
>     feature? Any help will be appreciated.
> 
> I have found the problem. ofono does not apply ACCM, which is proposed by the 

So you're on the right track, but I think you're coming to the wrong conclusion. 
  Things are a bit more subtle than that.

> 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 

No, this is not correct.   oFono does honor the ACCM sent by the modem.  This 
happens in lcp_rcr().   Look around ppp_lcp.c:321 or so.  We apply the options 
just prior to sending the ack.

Remember, there are two ACCMs, the transmit and the receive.  Refer to RFC 1662, 
Section 7.1:

"Each end of the asynchronous link maintains two Async-Control-Character-Maps. 
The receiving ACCM is 32 bits, but the sending ACCM may be up to 256 bits.  This 
results in four distinct ACCMs, two in each direction of the link."

The receive ACCM is the issue here.  RFC 1662 also says:
"For asynchronous links, the default receiving ACCM is 0xffffffff.  The default 
sending ACCM is 0xffffffff, plus the Control Escape  and Flag Sequence 
characters themselves, plus whatever other outgoing characters are flagged (by 
prior configuration) as likely to be intercepted."

GAtPPP basically doesn't want or need to re-negotiate the default ACCM, hence we 
do not send an ACCM to the peer, expecting it to use the defaults.  See 
lcp_generate_config_options().  REQ_OPTION_ACCM is never set.  What this means 
is that when the peer acks our options and we call lcp_rca in 
pppcp_process_configure_ack(), the ACCM option is not present.  Hence the code 
for setting the ACCM in lcp_rca() is never triggered.

So I suspect what is happening is that your Quectel modem assumes that not 
requesting the ACCM means having a zero ACCM instead of the RFC-mandated default.

So far, all modems on this planet have honored the default properly...

> 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?

So you have two options for fixing this:
   - Make GAtPPP negotiate a default ACCM in all cases
   - Override the negotiated ACCM (using g_at_hdlc_set_recv_accm for your 
particular modem.

> 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.
> 

We only support PPP over serial ports or emulated serial ports, which have to 
use ACCM.  I'm not aware of any other possibilities.

Regards,
-Denis