All of lore.kernel.org
 help / color / mirror / Atom feed
* PPP connection to a private APN
@ 2013-08-02 15:31 Etienne Mabille
  2013-08-02 16:00 ` Denis Kenzior
  0 siblings, 1 reply; 13+ messages in thread
From: Etienne Mabille @ 2013-08-02 15:31 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 447 bytes --]

Hi everyone,

I am forced to work with version 1.3 of oFono and I want to setup a ppp
connection on a private APN.
It works well on a public APN but not on the private one. I looked at the
debug trace and it seems like oFono doesn't give the username and password
anywhere in the AT commands.
Is this function possible ? If so, does anyone know when this feature was
added so I can add a patch to my version ?

Best regards,

Etienne

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 543 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-02 15:31 PPP connection to a private APN Etienne Mabille
@ 2013-08-02 16:00 ` Denis Kenzior
  2013-08-07 14:10   ` Etienne
  0 siblings, 1 reply; 13+ messages in thread
From: Denis Kenzior @ 2013-08-02 16:00 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 1169 bytes --]

Hi Etienne,

On 08/02/2013 10:31 AM, Etienne Mabille wrote:
> Hi everyone,
>
> I am forced to work with version 1.3 of oFono and I want to setup a ppp
> connection on a private APN.
> It works well on a public APN but not on the private one. I looked at
> the debug trace and it seems like oFono doesn't give the username and
> password anywhere in the AT commands.
> Is this function possible ? If so, does anyone know when this feature
> was added so I can add a patch to my version ?
>

Your subject mentions a 'PPP' connection.  So I assume you're using a 
modem which uses PPP.  If so, then the user/password exchange is done 
over the PPP link and not AT commands.  You will have to debug the PPP 
connection in order to understand what fails.

The gatchat library actually has a nice tool that might help.  It uses 
the oFono internal PPP implementation and can make basic context 
activations.  See gatchat/gsmdial.c for reference.

The tool also supports PPPdump file output (use --pppdump option to set 
a filename).  You can then view the detailed transaction log with 
wireshark or another protocol analyzer.

Regards,
-Denis


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-02 16:00 ` Denis Kenzior
@ 2013-08-07 14:10   ` Etienne
  2013-08-07 15:41     ` Denis Kenzior
  2013-08-07 16:12     ` Marcel Holtmann
  0 siblings, 2 replies; 13+ messages in thread
From: Etienne @ 2013-08-07 14:10 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 7323 bytes --]


Denis Kenzior <denkenz@...> writes:

> 
> Hi Etienne,
> 
> On 08/02/2013 10:31 AM, Etienne Mabille wrote:
> > Hi everyone,
> >
> > I am forced to work with version 1.3 of oFono and I want to setup a ppp
> > connection on a private APN.
> > It works well on a public APN but not on the private one. I looked at
> > the debug trace and it seems like oFono doesn't give the username and
> > password anywhere in the AT commands.
> > Is this function possible ? If so, does anyone know when this feature
> > was added so I can add a patch to my version ?
> >
> 
> Your subject mentions a 'PPP' connection.  So I assume you're using a 
> modem which uses PPP.  If so, then the user/password exchange is done 
> over the PPP link and not AT commands.  You will have to debug the PPP 
> connection in order to understand what fails.
> 
> The gatchat library actually has a nice tool that might help.  It uses 
> the oFono internal PPP implementation and can make basic context 
> activations.  See gatchat/gsmdial.c for reference.
> 
> The tool also supports PPPdump file output (use --pppdump option to set 
> a filename).  You can then view the detailed transaction log with 
> wireshark or another protocol analyzer.
> 
> Regards,
> -Denis
> 
> 

Hi Denis

Thank you for your help, I managed to obtain a dump of the ppp connection
and I compared it with the ppp debug info from ofono. 

The modem negociates with the DCE for the correct DNS and IP addresses. But
the modem receives a "CGEV: NW DEACT X25" message before obtaining the IP
address. I checked the dump with wireshark, there is no exchange of username
and password. Do you know if this is supposed to happen before or after
obtention of the IP address ?

I am also wondering what are the possible causes of a "NW DEACT" ? 

I tried with the same computer, sim card, APN, credentials, but another
modem (Option GTM382, does not use the PPP module from ofono) and it
connects fine.

Here is the log from ofono :

ofonod[1911]: drivers/atmodem/network-registration.c:cops_cb() cops_cb:
BOUYGTEL, 208 20 2
ofonod[1911]: src/network.c:current_operator_callback() 0x82ea648, 0x82f0a68
ofonod[1911]: Aux: < \r\n+CIEV: rssi,3\r\n\r\n+CIEV: service,1\r\n\r\n+CIEV:
roam,0\r\n
ofonod[1911]: drivers/atmodem/gprs-context.c:at_gprs_activate_primary() cid 1
ofonod[1911]: Modem: > AT+CGDCONT=1,"IP","alstom-france-locomotive.fr"\r
ofonod[1911]: Modem: < \r\nOK\r\n
ofonod[1911]: drivers/atmodem/gprs-context.c:at_cgdcont_cb() ok 1
ofonod[1911]: Modem: > AT+CGDATA="PPP",1\r
ofonod[1911]: Modem: < \r\nCONNECT\r\n
ofonod[1911]: drivers/atmodem/gprs-context.c:at_cgdata_cb() ok 1
ofonod[1911]: drivers/atmodem/gprs-context.c:setup_ppp()
ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 0:INITIAL
ofonod[1911]: PPP: event: 0 (Up), action: 2, new_state: 2 (CLOSED)
ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 2:CLOSED
ofonod[1911]: PPP: event: 2 (Open), action: 1026, new_state: 6 (REQSENT)
ofonod[1911]: PPP: lcp: pppcp_initialize_restart_count: current state 2:CLOSED
ofonod[1911]: PPP: lcp: pppcp_send_configure_request: current state 2:CLOSED
ofonod[1911]: PPP: gatchat/gatppp.c:ppp_enter_phase() 1
ofonod[1911]: PPP: lcp: pppcp_process_configure_request: current state 6:REQSENT
ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
ofonod[1911]: PPP: event: 6 (RCR+), action: 2008, new_state: 8 (ACKSENT)
ofonod[1911]: PPP: lcp: pppcp_send_configure_ack: current state 6:REQSENT
ofonod[1911]: PPP: lcp: pppcp_process_configure_ack: current state 8:ACKSENT
ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 8:ACKSENT
ofonod[1911]: PPP: event: 8 (RCA), action: 129, new_state: 9 (OPENED)
ofonod[1911]: PPP: lcp: pppcp_initialize_restart_count: current state 8:ACKSENT
ofonod[1911]: PPP: gatchat/gatppp.c:ppp_enter_phase() 3
ofonod[1911]: PPP: ipcp: pppcp_generate_event: current state 0:INITIAL
ofonod[1911]: PPP: event: 2 (Open), action: 401, new_state: 1 (STARTING)
ofonod[1911]: PPP: ipcp: pppcp_generate_event: current state 1:STARTING
ofonod[1911]: PPP: event: 0 (Up), action: 1026, new_state: 6 (REQSENT)
ofonod[1911]: PPP: ipcp: pppcp_initialize_restart_count: current state
1:STARTING
ofonod[1911]: PPP: ipcp: pppcp_send_configure_request: current state 1:STARTING
ofonod[1911]: PPP: ipcp: pppcp_process_configure_nak: current state 6:REQSENT
ofonod[1911]: PPP: ipcp: pppcp_generate_event: current state 6:REQSENT
ofonod[1911]: PPP: event: 9 (RCN), action: 1026, new_state: 6 (REQSENT)
ofonod[1911]: PPP: ipcp: pppcp_initialize_restart_count: current state 6:REQSENT
ofonod[1911]: PPP: ipcp: pppcp_send_configure_request: current state 6:REQSENT
ofonod[1911]: PPP: ipcp: pppcp_process_configure_nak: current state 6:REQSENT
ofonod[1911]: PPP: ipcp: pppcp_generate_event: current state 6:REQSENT
ofonod[1911]: PPP: event: 9 (RCN), action: 1026, new_state: 6 (REQSENT)
ofonod[1911]: PPP: ipcp: pppcp_initialize_restart_count: current state 6:REQSENT
ofonod[1911]: PPP: ipcp: pppcp_send_configure_request: current state 6:REQSENT
ofonod[1911]: Aux: < \r\n+CGEV: NW DEACT X25, "", 1\r\n
ofonod[1911]: drivers/atmodem/gprs-context.c:cgev_notify() cid 1
ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 9:OPENED
ofonod[1911]: PPP: event: 3 (Close), action: 8224, new_state: 4 (CLOSING)
ofonod[1911]: PPP: lcp: pppcp_initialize_restart_count: current state 9:OPENED
ofonod[1911]: PPP: lcp: pppcp_send_terminate_request: current state 9:OPENED
ofonod[1911]: PPP: ipcp: pppcp_generate_event: current state 6:REQSENT
ofonod[1911]: PPP: event: 1 (Down), action: 1, new_state: 1 (STARTING)
ofonod[1911]: PPP: gatchat/gatppp.c:ppp_enter_phase() 5
ofonod[1911]: Aux: < \r\n
ofonod[1911]: Aux: < +CGEV: ME DEACT X25, "", 1\r\n
ofonod[1911]: PPP: lcp: pppcp_process_terminate_request: current state 4:CLOSING
ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 4:CLOSING
ofonod[1911]: PPP: event: 10 (RTR), action: 10004, new_state: 4 (CLOSING)
ofonod[1911]: PPP: lcp: pppcp_send_terminate_ack: current state 4:CLOSING
ofonod[1911]: PPP: gatchat/gatppp.c:sta_sent()
ofonod[1911]: Aux: < \r\n+CGREG: 0\r\n\r\n+CGEV: NW DETACH\r\n
ofonod[1911]: src/gprs.c:ofono_gprs_status_notify() /telit_0 status 0
ofonod[1911]: src/gprs.c:ofono_gprs_detached_notify() /telit_0
ofonod[1911]: PPP: lcp: pppcp_timeout: current state 4:CLOSING
ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 4:CLOSING
ofonod[1911]: PPP: event: 4 (TO+), action: 8004, new_state: 4 (CLOSING)
ofonod[1911]: PPP: lcp: pppcp_send_terminate_request: current state 4:CLOSING
ofonod[1911]: PPP: lcp: pppcp_timeout: current state 4:CLOSING
ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 4:CLOSING
ofonod[1911]: PPP: event: 5 (TO-), action: 802, new_state: 2 (CLOSED)
ofonod[1911]: PPP: lcp: pppcp_this_layer_finished: current state 2:CLOSED
ofonod[1911]: PPP: gatchat/gatppp.c:ppp_enter_phase() 0
ofonod[1911]: PPP: gatchat/gatppp.c:ppp_dead()
ofonod[1911]: drivers/atmodem/gprs-context.c:ppp_disconnect()
ofonod[1911]: src/gprs.c:pri_activate_callback() 0x82f0430
ofonod[1911]: src/gprs.c:pri_activate_callback() Activating context failed
with error: Unknown error type

Regards,

Etienne



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-07 14:10   ` Etienne
@ 2013-08-07 15:41     ` Denis Kenzior
  2013-08-07 16:12     ` Marcel Holtmann
  1 sibling, 0 replies; 13+ messages in thread
From: Denis Kenzior @ 2013-08-07 15:41 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 3989 bytes --]

Hi Etienne,

 >
> Thank you for your help, I managed to obtain a dump of the ppp connection
> and I compared it with the ppp debug info from ofono.
>
> The modem negociates with the DCE for the correct DNS and IP addresses. But
> the modem receives a "CGEV: NW DEACT X25" message before obtaining the IP
> address. I checked the dump with wireshark, there is no exchange of username
> and password. Do you know if this is supposed to happen before or after
> obtention of the IP address ?

The way this is setup is slightly weird in GSM.  The PPP stack runs on 
the modem and it is supposed to ask for credential information and 
transparently forward it to the network during context activation.

 From your log it seems that the modem never asks for authentication 
information.  There could be several reasons for this, it might not 
support any authentication protocol, it might not support the auth 
protocol we support (CHAP + MD5), etc.  You will need to examine the 
wireshark results for why this happens.  But essentially the 
authentication phase is skipped.

>
> I am also wondering what are the possible causes of a "NW DEACT" ?

The network drops the GPRS connection.  Speculating here, but I suspect 
it is because the credentials are invalid ;)

>
> I tried with the same computer, sim card, APN, credentials, but another
> modem (Option GTM382, does not use the PPP module from ofono) and it
> connects fine.
>

I would try also with pppd and generate pppdump information.  If this 
succeeds then I would compare the two wireshark logs to figure out what 
goes wrong.  oFono supports the bare minimum of PPP that works on 99% of 
the hardware.  But honestly we never tried VPN style GPRS contexts, so 
it may be that we are missing something.

> Here is the log from ofono :
>
> ofonod[1911]: drivers/atmodem/network-registration.c:cops_cb() cops_cb:
> BOUYGTEL, 208 20 2
> ofonod[1911]: src/network.c:current_operator_callback() 0x82ea648, 0x82f0a68
> ofonod[1911]: Aux: < \r\n+CIEV: rssi,3\r\n\r\n+CIEV: service,1\r\n\r\n+CIEV:
> roam,0\r\n
> ofonod[1911]: drivers/atmodem/gprs-context.c:at_gprs_activate_primary() cid 1
> ofonod[1911]: Modem: > AT+CGDCONT=1,"IP","alstom-france-locomotive.fr"\r
> ofonod[1911]: Modem: < \r\nOK\r\n
> ofonod[1911]: drivers/atmodem/gprs-context.c:at_cgdcont_cb() ok 1
> ofonod[1911]: Modem: > AT+CGDATA="PPP",1\r
> ofonod[1911]: Modem: < \r\nCONNECT\r\n
> ofonod[1911]: drivers/atmodem/gprs-context.c:at_cgdata_cb() ok 1
> ofonod[1911]: drivers/atmodem/gprs-context.c:setup_ppp()
> ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 0:INITIAL
> ofonod[1911]: PPP: event: 0 (Up), action: 2, new_state: 2 (CLOSED)
> ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 2:CLOSED
> ofonod[1911]: PPP: event: 2 (Open), action: 1026, new_state: 6 (REQSENT)
> ofonod[1911]: PPP: lcp: pppcp_initialize_restart_count: current state 2:CLOSED
> ofonod[1911]: PPP: lcp: pppcp_send_configure_request: current state 2:CLOSED
> ofonod[1911]: PPP: gatchat/gatppp.c:ppp_enter_phase() 1

Just FYI: Here we enter PPP_PHASE_ESTABLISHMENT

> ofonod[1911]: PPP: lcp: pppcp_process_configure_request: current state 6:REQSENT
> ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 6:REQSENT
> ofonod[1911]: PPP: event: 6 (RCR+), action: 2008, new_state: 8 (ACKSENT)
> ofonod[1911]: PPP: lcp: pppcp_send_configure_ack: current state 6:REQSENT
> ofonod[1911]: PPP: lcp: pppcp_process_configure_ack: current state 8:ACKSENT
> ofonod[1911]: PPP: lcp: pppcp_generate_event: current state 8:ACKSENT
> ofonod[1911]: PPP: event: 8 (RCA), action: 129, new_state: 9 (OPENED)
> ofonod[1911]: PPP: lcp: pppcp_initialize_restart_count: current state 8:ACKSENT
> ofonod[1911]: PPP: gatchat/gatppp.c:ppp_enter_phase() 3

Here we enter PPP_PHASE_NETWORK.  The PPP_PHASE_AUTHENTICATION is 
skipped because it was never negotiated in the ESTABLISHMENT phase.

Regards,
-Denis

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-07 14:10   ` Etienne
  2013-08-07 15:41     ` Denis Kenzior
@ 2013-08-07 16:12     ` Marcel Holtmann
  2013-08-07 23:30       ` Denis Kenzior
  1 sibling, 1 reply; 13+ messages in thread
From: Marcel Holtmann @ 2013-08-07 16:12 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

Hi Etienne,

>>> I am forced to work with version 1.3 of oFono and I want to setup a ppp
>>> connection on a private APN.
>>> It works well on a public APN but not on the private one. I looked at
>>> the debug trace and it seems like oFono doesn't give the username and
>>> password anywhere in the AT commands.
>>> Is this function possible ? If so, does anyone know when this feature
>>> was added so I can add a patch to my version ?
>>> 
>> 
>> Your subject mentions a 'PPP' connection.  So I assume you're using a 
>> modem which uses PPP.  If so, then the user/password exchange is done 
>> over the PPP link and not AT commands.  You will have to debug the PPP 
>> connection in order to understand what fails.
>> 
>> The gatchat library actually has a nice tool that might help.  It uses 
>> the oFono internal PPP implementation and can make basic context 
>> activations.  See gatchat/gsmdial.c for reference.
>> 
>> The tool also supports PPPdump file output (use --pppdump option to set 
>> a filename).  You can then view the detailed transaction log with 
>> wireshark or another protocol analyzer.
> Thank you for your help, I managed to obtain a dump of the ppp connection
> and I compared it with the ppp debug info from ofono. 
> 
> The modem negociates with the DCE for the correct DNS and IP addresses. But
> the modem receives a "CGEV: NW DEACT X25" message before obtaining the IP
> address. I checked the dump with wireshark, there is no exchange of username
> and password. Do you know if this is supposed to happen before or after
> obtention of the IP address ?

is your private APN really an X25 network? We would normally expect types of IP, IPV6 or IPV4V6 and not plain X25. Are you asking for X25 network via AT+CGDCONT or does the network turn it into one?

Regards

Marcel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-07 16:12     ` Marcel Holtmann
@ 2013-08-07 23:30       ` Denis Kenzior
  2013-08-08  1:03         ` Marcel Holtmann
  0 siblings, 1 reply; 13+ messages in thread
From: Denis Kenzior @ 2013-08-07 23:30 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

Hi Marcel,
 >
> is your private APN really an X25 network? We would normally expect types of IP, IPV6 or IPV4V6 and not plain X25. Are you asking for X25 network via AT+CGDCONT or does the network turn it into one?
>

The CGDCONT is quite clearly using an IP context type.  We don't even 
support X25 context type btw ;)

ofonod[1911]: Modem: > AT+CGDCONT=1,"IP","...."\r
ofonod[1911]: Modem: < \r\nOK\r\n
ofonod[1911]: drivers/atmodem/gprs-context.c:at_cgdcont_cb() ok 1
ofonod[1911]: Modem: > AT+CGDATA="PPP",1\r
ofonod[1911]: Modem: < \r\nCONNECT\r\n

Regards,
-Denis

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-07 23:30       ` Denis Kenzior
@ 2013-08-08  1:03         ` Marcel Holtmann
  2013-08-09  9:11           ` Etienne
  0 siblings, 1 reply; 13+ messages in thread
From: Marcel Holtmann @ 2013-08-08  1:03 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

Hi Denis,

>> is your private APN really an X25 network? We would normally expect types of IP, IPV6 or IPV4V6 and not plain X25. Are you asking for X25 network via AT+CGDCONT or does the network turn it into one?
>> 
> 
> The CGDCONT is quite clearly using an IP context type.  We don't even support X25 context type btw ;)
> 
> ofonod[1911]: Modem: > AT+CGDCONT=1,"IP","...."\r
> ofonod[1911]: Modem: < \r\nOK\r\n
> ofonod[1911]: drivers/atmodem/gprs-context.c:at_cgdcont_cb() ok 1
> ofonod[1911]: Modem: > AT+CGDATA="PPP",1\r
> ofonod[1911]: Modem: < \r\nCONNECT\r\n

maybe SIM Toolkit is turning this into an X25 connection ;)

Or the modem firmware is fully confused and not able to handle this. Time to try this with a different modem. For example an Ericsson MBM or Qualcomm QMI.

Regards

Marcel


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-08  1:03         ` Marcel Holtmann
@ 2013-08-09  9:11           ` Etienne
  2013-08-09  9:37             ` Etienne
  2013-08-09 14:24             ` Denis Kenzior
  0 siblings, 2 replies; 13+ messages in thread
From: Etienne @ 2013-08-09  9:11 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 2832 bytes --]

Marcel Holtmann <marcel@...> writes:

> 
> Hi Denis,
> 
> >> is your private APN really an X25 network? We would normally expect
types of IP, IPV6 or IPV4V6 and not
> plain X25. Are you asking for X25 network via AT+CGDCONT or does the
network turn it into one?
> >> 
> > 
> > The CGDCONT is quite clearly using an IP context type.  We don't even
support X25 context type btw ;)
> > 
> > ofonod[1911]: Modem: > AT+CGDCONT=1,"IP","...."\r
> > ofonod[1911]: Modem: < \r\nOK\r\n
> > ofonod[1911]: drivers/atmodem/gprs-context.c:at_cgdcont_cb() ok 1
> > ofonod[1911]: Modem: > AT+CGDATA="PPP",1\r
> > ofonod[1911]: Modem: < \r\nCONNECT\r\n
> 
> maybe SIM Toolkit is turning this into an X25 connection ;)
> 
> Or the modem firmware is fully confused and not able to handle this. Time
to try this with a different modem.
> For example an Ericsson MBM or Qualcomm QMI.
> 
> Regards
> 
> Marcel
> 
> 

Hi all,

So we managed to solve our problem, we found out how to connect to a private
apn, but we have some questions to clear things up.

We compared the sequence of AT commands sent by ofono and by network manager
for the same modem (Telit HE910).
One difference is during the activation of the context :

    - ofono uses the 'AT+CGDATA="PPP",<cid>'  
the driver used by the telit is the atmodem. This command doesn't appear in
the documentation for the Telit HE910, but it still replied OK. However in
the dumps from ppp, we saw that the DCE does not ask for any authentication
protocol. So the modem doesn't send its credentials, and the DCE eventually
forces a deactivation.
 
    - network manager used 'ATD*99***#<cid>'
With this command, the DCE asks for an authentication protocol. The modem
then sends its credentials and the connection is completed.


I am not quite sure why the first command does not work while the second
does and I am very interested in having an explanation if you have one.
Should we use another driver than the atmodem ? one that uses the ATD command ? 


Another topic is the authentication protocol. By default the Telit HE910
uses PAP which is not handled by ofono. 
I started to implement it in gatchat/ppp_auth.c it is not quite perfect
because it does not ask to do CHAP before falling back to PAP but if anyone
is interested i would be glad to share the code. 
We then found out that there is a custom AT command for the Telit HE910 that
allows you to set the authentication protocol to use : AT#CGAUTH=[0,1, or 2]
I added it in plugins/telit.c in the post_online function and stopped
working on PAP. (I am using the telit rework patch provided by Jonas Bonn on
the 4th of April)

At the moment i just modified the source with these modifications, and it
works nice.

Thank you for your help,
Regards, 

Etienne




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-09  9:11           ` Etienne
@ 2013-08-09  9:37             ` Etienne
  2013-08-09 14:24             ` Denis Kenzior
  1 sibling, 0 replies; 13+ messages in thread
From: Etienne @ 2013-08-09  9:37 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Etienne <mabille.etienne@...> writes:

>     - network manager used 'ATD*99***#<cid>'
> With this command, the DCE asks for an authentication protocol. The modem
> then sends its credentials and the connection is completed.


Sorry I just noticed a mistake, the command used by network manager is 
'ATD*99***<cid>#'
The # is at the end

Etienne



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-09  9:11           ` Etienne
  2013-08-09  9:37             ` Etienne
@ 2013-08-09 14:24             ` Denis Kenzior
  2013-08-12  9:19               ` Etienne Mabille
  1 sibling, 1 reply; 13+ messages in thread
From: Denis Kenzior @ 2013-08-09 14:24 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 2599 bytes --]

Hi Etienne,

 >
> So we managed to solve our problem, we found out how to connect to a private
> apn, but we have some questions to clear things up.
>
> We compared the sequence of AT commands sent by ofono and by network manager
> for the same modem (Telit HE910).
> One difference is during the activation of the context :
>
>      - ofono uses the 'AT+CGDATA="PPP",<cid>'
> the driver used by the telit is the atmodem. This command doesn't appear in
> the documentation for the Telit HE910, but it still replied OK. However in
> the dumps from ppp, we saw that the DCE does not ask for any authentication
> protocol. So the modem doesn't send its credentials, and the DCE eventually
> forces a deactivation.
>
>      - network manager used 'ATD*99***#<cid>'
> With this command, the DCE asks for an authentication protocol. The modem
> then sends its credentials and the connection is completed.
>
>
> I am not quite sure why the first command does not work while the second
> does and I am very interested in having an explanation if you have one.
> Should we use another driver than the atmodem ? one that uses the ATD command ?
>

So in theory the ATD*99... variation is a legacy context activation 
command.  It is described in 27.007 Section 10.2.1.1 Request Packet 
Domain service 'D'.  It is supposed to be superseded by AT+CGDATA, but 
many manufacturers have not updated their firmware properly.  oFono 
supports both, you might need to set a quirk if one is preferred over 
the other.

>
> Another topic is the authentication protocol. By default the Telit HE910
> uses PAP which is not handled by ofono.
> I started to implement it in gatchat/ppp_auth.c it is not quite perfect
> because it does not ask to do CHAP before falling back to PAP but if anyone
> is interested i would be glad to share the code.
> We then found out that there is a custom AT command for the Telit HE910 that
> allows you to set the authentication protocol to use : AT#CGAUTH=[0,1, or 2]
> I added it in plugins/telit.c in the post_online function and stopped
> working on PAP. (I am using the telit rework patch provided by Jonas Bonn on
> the 4th of April)

Does this work with CGDATA?  If that is the case it might explain why 
CGDATA does not ask for authentication.  You can enable this command 
inside drivers/atmodem/gprs-context.c with the appropriate OFONO_VENDOR 
handling as well.

Patches are always welcome.

>
> At the moment i just modified the source with these modifications, and it
> works nice.
>

No problem.

Regards,
-Denis

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-09 14:24             ` Denis Kenzior
@ 2013-08-12  9:19               ` Etienne Mabille
  2013-08-12  9:28                 ` Jesper Larsen
  0 siblings, 1 reply; 13+ messages in thread
From: Etienne Mabille @ 2013-08-12  9:19 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

2013/8/9 Denis Kenzior <denkenz@gmail.com>

>


>> Another topic is the authentication protocol. By default the Telit HE910
>> uses PAP which is not handled by ofono.
>> I started to implement it in gatchat/ppp_auth.c it is not quite perfect
>> because it does not ask to do CHAP before falling back to PAP but if
>> anyone
>> is interested i would be glad to share the code.
>> We then found out that there is a custom AT command for the Telit HE910
>> that
>> allows you to set the authentication protocol to use : AT#CGAUTH=[0,1, or
>> 2]
>> I added it in plugins/telit.c in the post_online function and stopped
>> working on PAP. (I am using the telit rework patch provided by Jonas Bonn
>> on
>> the 4th of April)
>>
>
> Does this work with CGDATA?  If that is the case it might explain why
> CGDATA does not ask for authentication.  You can enable this command inside
> drivers/atmodem/gprs-context.c with the appropriate OFONO_VENDOR handling
> as well.
>
>
The CGDATA does not work with the Telit modem, whatever the value of
AT#CGAUTH is. In my case, ATD*99 is absolutely necessary. The CGAUTH
command is just there to use CHAP instead of PAP because ofono doesn't
handle it.


> Patches are always welcome.
>

I am trying to do a clean patch in drivers/atmodem/gprs-context.c but for
some reason the field gcd->vendor is equal to 0 so it doesn't match with
OFONO_VENDOR_TELIT.
The two AT commands are the following :

// in at_gprs_activate_primary :

if (gcd->vendor == OFONO_VENDOR_TELIT){
    /*
     * Set the modem to use CHAP authentication if needed.
     * Telit modems use PAP by default which is not supported
     * by ofono.
     */
     g_at_chat_send(gcd->chat, "AT#GAUTH=2", none_prefix, NULL, NULL, NULL);
}



// in  at_cgdcont_cb :
if (gcd->vendor == OFONO_VENDOR_TELIT){
    /*
     * With Telit AT+CGDATA prevents the DCE from offering
     * an authentication protocol, so we use this command in
     * case we need to connect to a private APN.
     */

    sprintf(buf, "ATD*99***%u#", gcd->active_context);
}

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 3006 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-12  9:19               ` Etienne Mabille
@ 2013-08-12  9:28                 ` Jesper Larsen
  2013-08-12 12:43                   ` Etienne
  0 siblings, 1 reply; 13+ messages in thread
From: Jesper Larsen @ 2013-08-12  9:28 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 2764 bytes --]

On Mon, Aug 12, 2013 at 11:19 AM, Etienne Mabille <mabille.etienne@gmail.com
> wrote:

> 2013/8/9 Denis Kenzior <denkenz@gmail.com>
>
>>
>
>
>>> Another topic is the authentication protocol. By default the Telit HE910
>>> uses PAP which is not handled by ofono.
>>> I started to implement it in gatchat/ppp_auth.c it is not quite perfect
>>> because it does not ask to do CHAP before falling back to PAP but if
>>> anyone
>>> is interested i would be glad to share the code.
>>> We then found out that there is a custom AT command for the Telit HE910
>>> that
>>> allows you to set the authentication protocol to use : AT#CGAUTH=[0,1,
>>> or 2]
>>> I added it in plugins/telit.c in the post_online function and stopped
>>> working on PAP. (I am using the telit rework patch provided by Jonas
>>> Bonn on
>>> the 4th of April)
>>>
>>
>> Does this work with CGDATA?  If that is the case it might explain why
>> CGDATA does not ask for authentication.  You can enable this command inside
>> drivers/atmodem/gprs-context.c with the appropriate OFONO_VENDOR handling
>> as well.
>>
>>
> The CGDATA does not work with the Telit modem, whatever the value of
> AT#CGAUTH is. In my case, ATD*99 is absolutely necessary. The CGAUTH
> command is just there to use CHAP instead of PAP because ofono doesn't
> handle it.
>
>
>> Patches are always welcome.
>>
>
> I am trying to do a clean patch in drivers/atmodem/gprs-context.c but for
> some reason the field gcd->vendor is equal to 0 so it doesn't match with
> OFONO_VENDOR_TELIT.
>


Vendor is set when creating the gprs context in telit_post_sim()
(plugins/tellit.c:561)

gprs = ofono_gprs_create(modem, OFONO_VENDOR_TELIT, "atmodem",
data->chat);
gc = ofono_gprs_context_create(modem, 0, "atmodem", data->modem);

You need to change the second argument from 0 to OFONO_VENDOR_TELIT



> The two AT commands are the following :
>
> // in at_gprs_activate_primary :
>
> if (gcd->vendor == OFONO_VENDOR_TELIT){
>     /*
>      * Set the modem to use CHAP authentication if needed.
>      * Telit modems use PAP by default which is not supported
>      * by ofono.
>      */
>      g_at_chat_send(gcd->chat, "AT#GAUTH=2", none_prefix, NULL, NULL,
> NULL);
> }
>
>
>
> // in  at_cgdcont_cb :
> if (gcd->vendor == OFONO_VENDOR_TELIT){
>     /*
>      * With Telit AT+CGDATA prevents the DCE from offering
>      * an authentication protocol, so we use this command in
>      * case we need to connect to a private APN.
>      */
>
>     sprintf(buf, "ATD*99***%u#", gcd->active_context);
> }
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> https://lists.ofono.org/mailman/listinfo/ofono
>
>

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 4819 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PPP connection to a private APN
  2013-08-12  9:28                 ` Jesper Larsen
@ 2013-08-12 12:43                   ` Etienne
  0 siblings, 0 replies; 13+ messages in thread
From: Etienne @ 2013-08-12 12:43 UTC (permalink / raw)
  To: ofono

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Hi Jesper,

Perfect, this is all it needed. Thank you.

Etienne




^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2013-08-12 12:43 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-08-02 15:31 PPP connection to a private APN Etienne Mabille
2013-08-02 16:00 ` Denis Kenzior
2013-08-07 14:10   ` Etienne
2013-08-07 15:41     ` Denis Kenzior
2013-08-07 16:12     ` Marcel Holtmann
2013-08-07 23:30       ` Denis Kenzior
2013-08-08  1:03         ` Marcel Holtmann
2013-08-09  9:11           ` Etienne
2013-08-09  9:37             ` Etienne
2013-08-09 14:24             ` Denis Kenzior
2013-08-12  9:19               ` Etienne Mabille
2013-08-12  9:28                 ` Jesper Larsen
2013-08-12 12:43                   ` Etienne

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.