Re: Quectel EC200T USB: Problems with context activation

[tmtrendz360]

Hello, Denis Kenzior, It is worth a read cause your blog always has a piece of 
good and worthy information, You are quite a creative writer.
https://themarketingtrendz.com/
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[aneesayesha952]

Yes, really this Quectel EC200T USB: Problems with context activation, has too 
much to know about it, but the new and informative news is that the most 
essential Proton Motors Pakistan, https://proton.com.pk/ is giving their best 
cars in Pakistan for its consumer to get the latest experiences of Automobiles 
very easily.
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

Hi Denis,

On Fri, Mar 18, 2022 at 4:58 PM Denis Kenzior  wrote:

> > Do you think that we should keep the following unchanged in this case?
> >
> >  > As well as ofono/plugins/fileprovision.c::
> >  >
> >  >  /* select default authentication method */
> >  >  (*settings)[0].auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
> >  >
> >
>
> Not sure?  I think only a few folks use the file-provision plugin.  You
> can
> always send an RFC patch and see if anyone chimes in.
>
> Sure. I will.


> And, yes. I think that even just only revert of
> > a5bdf48ca7be70a9b33a47dae0ea03bf842efdd2 would be enough for my case.
> >
>
> Can you test that this indeed fixes your issue and send a 'git revert'
> commit
> with a proper commit description?  Essentially just a quick summary of
> this thread?
>

> Sure. I will do it. Give me a few weeks to test everything please as I am
a bit busy.

Best regards,
Sergei
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Denis Kenzior]

Hi Sergei,



Yes, I propose to revert that commit.



That sounds fine to me.


Do you think that we should keep the following unchanged in this case?

 > As well as ofono/plugins/fileprovision.c::
 >
 >      /* select default authentication method */
 >      (*settings)[0].auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
 >



Not sure?  I think only a few folks use the file-provision plugin.  You can 
always send an RFC patch and see if anyone chimes in.


And, yes. I think that even just only revert of 
a5bdf48ca7be70a9b33a47dae0ea03bf842efdd2 would be enough for my case.




Can you test that this indeed fixes your issue and send a 'git revert' commit 
with a proper commit description?  Essentially just a quick summary of this thread?


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

Hi Denis,

On Thu, Mar 17, 2022 at 8:38 PM Denis Kenzior  wrote:

> Hi Sergei,
>
> > The question is really whether it is the network or the modem at
> fault here.
> > Does AUTH_METHOD_NONE work on other networks with this hardware?
> >
> >
> > The HW shows the same result in the network of a different provider
> which also
> > has empty user/pass APN settings. I see that there are many similar
> providers
> > worldwide. Even in the US. T-Mobile for instance
> >
> https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/-/blob/main/serviceproviders.xml#L13394
> > <
> https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/-/blob/main/serviceproviders.xml#L13394>
>
> > .
>
> So from what I recall, we use CHAP by default if a username/password is
> provided
> and NONE otherwise.  This was added in commit:
> a5bdf48ca7be70a9b33a47dae0ea03bf842efdd2
>
> Also the LTE and GPRS contexts have slightly different behaviors.  The
> provisioning plugins (mbpi, file-provision) is only performed for GPRS.
> LTE is
> provisioned separately.
>
> Are you proposing that we revert the above commit?  Would that be enough
> or do
> we need other changes?
>
>
Yes, I propose to revert that commit.

Do you think that we should keep the following unchanged in this case?

> As well as ofono/plugins/fileprovision.c::
>
>  /* select default authentication method */
>  (*settings)[0].auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
>

And, yes. I think that even just only revert of
a5bdf48ca7be70a9b33a47dae0ea03bf842efdd2
would be enough for my case.


> Since the DTD for mbpi
> (
> https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/-/blob/main/serviceproviders.2.dtd)
>
> doesn't even list none as a valid authentication type, I would tend to
> think
> that the commit in question wasn't correct.
>
>
I agree.


> Regards,
> -Denis
>

Yours sincerely,
Sergei Golubtsov.
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Denis Kenzior]

Hi Sergei,


The question is really whether it is the network or the modem at fault here.
Does AUTH_METHOD_NONE work on other networks with this hardware?


The HW shows the same result in the network of a different provider which also 
has empty user/pass APN settings. I see that there are many similar providers 
worldwide. Even in the US. T-Mobile for instance 
https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/-/blob/main/serviceproviders.xml#L13394 
 
.


So from what I recall, we use CHAP by default if a username/password is provided 
and NONE otherwise.  This was added in commit:

a5bdf48ca7be70a9b33a47dae0ea03bf842efdd2

Also the LTE and GPRS contexts have slightly different behaviors.  The 
provisioning plugins (mbpi, file-provision) is only performed for GPRS.  LTE is 
provisioned separately.


Are you proposing that we revert the above commit?  Would that be enough or do 
we need other changes?


Since the DTD for mbpi 
(https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/-/blob/main/serviceproviders.2.dtd) 
doesn't even list none as a valid authentication type, I would tend to think 
that the commit in question wasn't correct.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

Hi Denis,

The discussion is pretty old but I got new data related to your question
which has been left unanswered at that moment as I had no information and
the discussion has been suspended because of that. I hope we can resume the
discussion to put the "final point". Please find additional details below.

On Thu, May 20, 2021 at 7:57 PM Denis Kenzior  wrote:

> Hi Sergei,
>
> On 5/19/21 6:35 PM, Sergei Golubtsov wrote:
> > Hi Denis,
> >
> > Thank you very much for your quick and helpful reply.
> >
> > The problem is a bit vulgar actually. That's a shame that I took your
> > time for that but I have another question as I am not sure about the
> > findings below.
>
> no worries.
>
> >
> > I had tried to get dump with gsmdial and gsmdial successfully
> > activated the context. So the problem is that we have authentication
> > method set to NONE in ofono. But gsmdial uses CHAP by default.
> > I have manually set the auth to CHAP for the context in ofono and
> > ofono successfully activated the context.
>
> Yes, oFono used to use CHAP by default, but this was changed a few years
> ago.
>
> > There is the provider info from mobile-broadband-provider-info about
> > my provider:
> >
> >  
> >  China Unicom
> >  
> >  
> >  
> >  
> >  
> >  uninet
> >  
> >  
> >  
> >  联通彩信
> >  http://mmsc.myuni.com.cn
> >  10.0.0.172:80
> >  
> >  
> >  
> >
> >
> > Am I correct that ofono must use CHAP if the auth method is not
> > specified in the db?
>
> We used to do this, then around Sep-Oct 2018 there was a strong push to
> add an
> explicit 'No Authentication' option for oFono from one of the modem
> hardware
> vendors.  I don't recall the exact arguments, search the archives, but the
> fallout was that an empty username / password implied no authentication.
> Which
> I think does make a certain amount of sense.
>
> git show 6cf24fe1f9cfa2a61422ad84abfdd32e7ea2cf78.  Look around at the
> commits
> from the same author.  I do seem to recall that 3GPP mandated CHAP to be
> used as
> the default, even in the no username / password case.  But my memory is
> fuzzy
> now, and there hasn't been any problems reported since then (until now).
>
> >
> > I see that the technology used by the modem is HSPA. And I see the
> > following in ofono/drivers/atmodem/lte.c:
> >
> >  /* change the authentication method if the  parameters are invalid
> */
> >  if (!*ldd->pending_info.username || !*ldd->pending_info.password)
> > auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
> >
> >
> > And in ofono/plugins/mbpi.c:
> >
> >  /* select authentication method NONE if fit */
> >  if (!ap->username || !ap->password)
> >  ap->auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
> >
> >
> > As well as ofono/plugins/fileprovision.c::
> >
> >  /* select default authentication method */
> >  (*settings)[0].auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
> >
> >
> > ofono/src/lte.c:
> >
> >  /* this must have a valid default */
> > if (!gprs_auth_method_from_string(auth_method_str,
> > >info.auth_method))
> > lte->info.auth_method = OFONO_GPRS_AUTH_METHOD_NONE;
> >
> >
> > I am not sure about the standards which may be relevant here. Sorry
> > for asking this but I thought that we should use CHAP by default,
> > don't we?
>
> The question is really whether it is the network or the modem at fault
> here.
> Does AUTH_METHOD_NONE work on other networks with this hardware?
>

The HW shows the same result in the network of a different provider which
also has empty user/pass APN settings. I see that there are many similar
providers worldwide. Even in the US. T-Mobile for instance
https://gitlab.gnome.org/GNOME/mobile-broadband-provider-info/-/blob/main/serviceproviders.xml#L13394
.

Should not we strictly follow 3GPP in ofono?


> >
> > Thank you again and have a nice day.
> >
> > Yours sincerely,
> > Sergei Golubtsov.
> >
>
> Regards,
> -Denis
>

Thank you!

Have a nice day.

Yours sincerely,
Sergei Golubtsov.
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Denis Kenzior]

Hi Sergei,

On 5/19/21 6:35 PM, Sergei Golubtsov wrote:

Hi Denis,

Thank you very much for your quick and helpful reply.

The problem is a bit vulgar actually. That's a shame that I took your
time for that but I have another question as I am not sure about the
findings below.


no worries.



I had tried to get dump with gsmdial and gsmdial successfully
activated the context. So the problem is that we have authentication
method set to NONE in ofono. But gsmdial uses CHAP by default.
I have manually set the auth to CHAP for the context in ofono and
ofono successfully activated the context.


Yes, oFono used to use CHAP by default, but this was changed a few years ago.


There is the provider info from mobile-broadband-provider-info about
my provider:

 
 China Unicom
 
 
 
 
 
 uninet
 
 
 
 联通彩信
 http://mmsc.myuni.com.cn
 10.0.0.172:80
 
 
 


Am I correct that ofono must use CHAP if the auth method is not
specified in the db?


We used to do this, then around Sep-Oct 2018 there was a strong push to add an 
explicit 'No Authentication' option for oFono from one of the modem hardware 
vendors.  I don't recall the exact arguments, search the archives, but the 
fallout was that an empty username / password implied no authentication.  Which 
I think does make a certain amount of sense.


git show 6cf24fe1f9cfa2a61422ad84abfdd32e7ea2cf78.  Look around at the commits 
from the same author.  I do seem to recall that 3GPP mandated CHAP to be used as 
the default, even in the no username / password case.  But my memory is fuzzy 
now, and there hasn't been any problems reported since then (until now).




I see that the technology used by the modem is HSPA. And I see the
following in ofono/drivers/atmodem/lte.c:

 /* change the authentication method if the  parameters are invalid */
 if (!*ldd->pending_info.username || !*ldd->pending_info.password)
auth_method = OFONO_GPRS_AUTH_METHOD_NONE;


And in ofono/plugins/mbpi.c:

 /* select authentication method NONE if fit */
 if (!ap->username || !ap->password)
 ap->auth_method = OFONO_GPRS_AUTH_METHOD_NONE;


As well as ofono/plugins/fileprovision.c::

 /* select default authentication method */
 (*settings)[0].auth_method = OFONO_GPRS_AUTH_METHOD_NONE;


ofono/src/lte.c:

 /* this must have a valid default */
if (!gprs_auth_method_from_string(auth_method_str,
>info.auth_method))
lte->info.auth_method = OFONO_GPRS_AUTH_METHOD_NONE;


I am not sure about the standards which may be relevant here. Sorry
for asking this but I thought that we should use CHAP by default,
don't we?


The question is really whether it is the network or the modem at fault here. 
Does AUTH_METHOD_NONE work on other networks with this hardware?




Thank you again and have a nice day.

Yours sincerely,
Sergei Golubtsov.



Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

Hi Denis,

Thank you very much for your quick and helpful reply.

The problem is a bit vulgar actually. That's a shame that I took your
time for that but I have another question as I am not sure about the
findings below.

I had tried to get dump with gsmdial and gsmdial successfully
activated the context. So the problem is that we have authentication
method set to NONE in ofono. But gsmdial uses CHAP by default.
I have manually set the auth to CHAP for the context in ofono and
ofono successfully activated the context.
There is the provider info from mobile-broadband-provider-info about
my provider:


China Unicom





uninet



联通彩信
http://mmsc.myuni.com.cn
10.0.0.172:80





Am I correct that ofono must use CHAP if the auth method is not
specified in the db?

I see that the technology used by the modem is HSPA. And I see the
following in ofono/drivers/atmodem/lte.c:

/* change the authentication method if the  parameters are invalid */
if (!*ldd->pending_info.username || !*ldd->pending_info.password)
   auth_method = OFONO_GPRS_AUTH_METHOD_NONE;


And in ofono/plugins/mbpi.c:

/* select authentication method NONE if fit */
if (!ap->username || !ap->password)
ap->auth_method = OFONO_GPRS_AUTH_METHOD_NONE;


As well as ofono/plugins/fileprovision.c::

/* select default authentication method */
(*settings)[0].auth_method = OFONO_GPRS_AUTH_METHOD_NONE;


ofono/src/lte.c:

/* this must have a valid default */
   if (!gprs_auth_method_from_string(auth_method_str,
   >info.auth_method))
   lte->info.auth_method = OFONO_GPRS_AUTH_METHOD_NONE;


I am not sure about the standards which may be relevant here. Sorry
for asking this but I thought that we should use CHAP by default,
don't we?

Thank you again and have a nice day.

Yours sincerely,
Sergei Golubtsov.
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Denis Kenzior]

Hi Sergei,

On 5/18/21 4:19 PM, Sergei Golubtsov wrote:

Hi Denis and all,

I have some problems with the context activation on Quectel EC200T USB in 
chinese network although in russian networks the modem works fine.


I have the following during the activation:

2021-05-18T23:35:50.624972+03:00 ofonod[999]: [info] Modem: < \r\nCONNECT\r\n
2021-05-18T23:35:50.625854+03:00 ofonod[999]: [debug] 
../git/ofono/drivers/atmodem/gprs-context.c:at_cgdata_cb() ok 1
2021-05-18T23:35:50.626564+03:00 ofonod[999]: [debug] 
../git/ofono/drivers/atmodem/gprs-context.c:setup_ppp()
2021-05-18T23:35:50.627463+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_generate_event: current state 0:INITIAL
2021-05-18T23:35:50.628216+03:00 ofonod[999]: [info] PPP: event: 0 (Up), action: 
2, new_state: 2 (CLOSED)
2021-05-18T23:35:50.628884+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_generate_event: current state 2:CLOSED
2021-05-18T23:35:50.629521+03:00 ofonod[999]: [info] PPP: event: 2 (Open), 
action: 1026, new_state: 6 (REQSENT)
2021-05-18T23:35:50.630234+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_initialize_restart_count: current state 2:CLOSED
2021-05-18T23:35:50.630876+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_send_configure_request: current state 2:CLOSED
2021-05-18T23:35:50.631641+03:00 ofonod[999]: [info] PPP: 
../git/ofono/gatchat/gatppp.c:ppp_enter_phase() 1
2021-05-18T23:35:50.634253+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_process_configure_request: current state 6:REQSENT
2021-05-18T23:35:50.635270+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_generate_event: current state 6:REQSENT
2021-05-18T23:35:50.635423+03:00 ofonod[999]: [info] PPP: event: 7 (RCR-), 
action: 4006, new_state: 6 (REQSENT)


Peer is sending us options we do not find acceptable...  Do you have a wireshark 
trace to see what this might be?


2021-05-18T23:35:50.635544+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_send_configure_nak: current state 6:REQSENT
2021-05-18T23:35:50.636566+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_process_configure_ack: current state 6:REQSENT


Looks like our options (that we're sending) are accepted by the peer

2021-05-18T23:35:50.636696+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_generate_event: current state 6:REQSENT
2021-05-18T23:35:50.637067+03:00 ofonod[999]: [info] PPP: event: 8 (RCA), 
action: 27, new_state: 7 (ACKRCVD)
2021-05-18T23:35:50.637187+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_initialize_restart_count: current state 6:REQSENT
2021-05-18T23:35:50.637187+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_initialize_restart_count: current state 6:REQSENT
2021-05-18T23:35:50.637597+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_process_configure_request: current state 7:ACKRCVD
2021-05-18T23:35:50.637715+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_generate_event: current state 7:ACKRCVD
2021-05-18T23:35:50.637826+03:00 ofonod[999]: [info] PPP: event: 7 (RCR-), 
action: 4007, new_state: 7 (ACKRCVD)
2021-05-18T23:35:50.637929+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_send_configure_nak: current state 7:ACKRCVD
2021-05-18T23:35:50.639907+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_process_configure_request: current state 7:ACKRCVD
2021-05-18T23:35:50.640246+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_generate_event: current state 7:ACKRCVD
2021-05-18T23:35:50.640992+03:00 ofonod[999]: [info] PPP: event: 7 (RCR-), 
action: 4007, new_state: 7 (ACKRCVD)


and basically we get into an infinite loop with the peer trying to set some 
options we find unacceptable..




So, the following lines repeats infinitely, context is not activated and ofono 
uses ~90% of the CPU until I stop it:
2021-05-18T23:35:50.637929+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_send_configure_nak: current state 7:ACKRCVD
2021-05-18T23:35:50.639907+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_process_configure_request: current state 7:ACKRCVD
2021-05-18T23:35:50.640246+03:00 ofonod[999]: [info] PPP: lcp: 
pppcp_generate_event: current state 7:ACKRCVD
2021-05-18T23:35:50.640992+03:00 ofonod[999]: [info] PPP: event: 7 (RCR-), 
action: 4007, new_state: 7 (ACKRCVD)


Could someone shed a light on what is going on there and how to solve that?

Thanks in advance.
Have a nice day.

Yours sincerely,
Sergei Golubtsov.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Denis Kenzior]

Hi Sergei,


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

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.

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 


I don't remember why we chose not to negotiate the RX ACCM.  Things may have 
worked wonderfully with the defaults, so maybe we just decided not to touch it.



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 = 
0x
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 


I think that makes sense.


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.


Well, it isn't a 'requirement' to use the defaults.  What happened in this 
particular case is that we didn't explicitly tell the modem side what RX ACCM we 
want, and the modem firmware didn't use the defined default values.


I think it should be safe for us to use an ACCM of 0 instead of the RFC default. 
 But just in case, we should probably provide a way for the driver to override 
it if needed.


So what I would do is:

- Set REQ_OPTION_ACCM in the lcp init somewhere.  Set the initial value to be 0 
as you suggest.
- Add g_at_ppp_set_accm() in order to allow drivers to provide a custom ACCM to 
negotiate, if needed.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

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.



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


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
= 0x
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.
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Denis Kenzior]

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 = 0x 
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 0x.  The default 
sending ACCM is 0x, 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  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
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

Hi Denis,

> 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 DCE in a configuration request. The EC200 Quectel modem uses ACCM =
0x 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
 3.3.5.2.

Regards,
Sergei.
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

Hi Denis,

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

Regards,
Sergei.
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

Hi Denis,

Thank you very much for your explanation. That was very helpful.

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


ofono_ppp_chap_dump.log
Description: Binary data


pppd_chap.dump
Description: Binary data


PPP-dump-hdlc-data.patch
Description: Binary data
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Denis Kenzior]

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 

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

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

> Looks fine...

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.

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

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:

> 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.
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  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 
> >  MessageCenter = http://mmsc:8002
> >  Settings = { }
> >  IPv6.Settings = { }
> >
>
> Looks fine...
>
> >  > 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 

Re: Quectel EC200T USB: Problems with context activation

[Denis Kenzior]

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 
         MessageCenter = http://mmsc:8002
         Settings = { }
         IPv6.Settings = { }



Looks fine...

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


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.


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.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

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

Yours sincerely,
Sergei Golubtsov.


EC200T_ofono_pap.log
Description: Binary data
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Denis Kenzior]

Hi Sergei,

On 12/29/20 11:56 AM, Sergei Golubtsov wrote:

Changing the authentication method to pap did not help. Please help.



Are the username and password set properly on the context?  And you may want to 
share the log of oFono activating the context configured for PAP.


Regards,
-Denis
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

Changing the authentication method to pap did not help. Please help.

Yours sincerely,
Sergei Golubtsov.


On Tue, Dec 29, 2020 at 4:55 PM Sergei Golubtsov 
wrote:

> In the first email I was mistaken about the authentication method in pppd
> - it is pap not chap. So, probably this is the problem. How can I change
> the authentication method for the context activation in Ofono from default
> chap to pap? Where is the best place to do it in the code?
>
> Yours sincerely,
> Sergei Golubtsov.
>
>
> On Tue, Dec 29, 2020 at 3:09 PM Sergei Golubtsov 
> wrote:
>
>> Hello,
>>
>> I am trying to add support for the Quectel EC200T USB modem. This modem
>> uses the option USB serial driver in the kernel.
>> As other Quectel modems, this one uses the atmodem ofono driver.
>>
>> I cannot overcome the problem of context activation. It fails at
>> "ofono/gatchat/gatppp.c:ppp_enter_phase() 2" after a minute.
>> At the same time, I can successfully use pppd. Both pppd and ofono use
>> the chap authentication method.
>>
>> Please find logs and the patch attached.
>> Any suggestions will be appreciated.
>>
>> Yours sincerely,
>> Sergei Golubtsov.
>>
>


EC200T_ofono_pap.log
Description: Binary data
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org

Re: Quectel EC200T USB: Problems with context activation

[Sergei Golubtsov]

In the first email I was mistaken about the authentication method in pppd -
it is pap not chap. So, probably this is the problem. How can I change the
authentication method for the context activation in Ofono from default chap
to pap? Where is the best place to do it in the code?

Yours sincerely,
Sergei Golubtsov.


On Tue, Dec 29, 2020 at 3:09 PM Sergei Golubtsov 
wrote:

> Hello,
>
> I am trying to add support for the Quectel EC200T USB modem. This modem
> uses the option USB serial driver in the kernel.
> As other Quectel modems, this one uses the atmodem ofono driver.
>
> I cannot overcome the problem of context activation. It fails at
> "ofono/gatchat/gatppp.c:ppp_enter_phase() 2" after a minute.
> At the same time, I can successfully use pppd. Both pppd and ofono use the
> chap authentication method.
>
> Please find logs and the patch attached.
> Any suggestions will be appreciated.
>
> Yours sincerely,
> Sergei Golubtsov.
>
___
ofono mailing list -- ofono@ofono.org
To unsubscribe send an email to ofono-le...@ofono.org