All of lore.kernel.org
 help / color / mirror / Atom feed
* no connection after ofono restart while huawei modem connected
@ 2018-07-13  7:47 Christophe Ronco
  2018-07-13 16:09 ` Denis Kenzior
  0 siblings, 1 reply; 8+ messages in thread
From: Christophe Ronco @ 2018-07-13  7:47 UTC (permalink / raw)
  To: ofono

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

Hi,

I use a Huawei MS2372h-607. It is a classical AT+PPP modem. I have a
problem when I stop ofono while context is activated. When I restart
ofono (without unplugging the modem), I am not able to send any AT
command on Modem channel because this channel is still in data mode.

I made a patch to send escape sequence when gprs-context atom is
removed. It fixes the problem but I don't know if this is the right
thing to do.

Attached to this mail:

I/ reconnectError_01: traces of complete test (with debug and AT debug).
Test done:

1) board boot

2) Connection (success), start at line 1058:

connmanctl connect cellular...

3) stop ofono, start at line 1109:

/etc/init.d/ofono stop

4) start ofono, start at line 1348:

/etc/init.d/ofono start

5) Connection (error), start at line 2018:

connmanctl connect cellular...


I don't have PPP debug in this trace but here is what happens at PPP
level when Ofono is stopped:

ofonod[944]:
../ofono-1.24/drivers/atmodem/gprs-context.c:at_gprs_detach_shutdown() cid 0
ofonod[944]: PPP: lcp: pppcp_generate_event: current state 9:OPENED
ofonod[944]: PPP: event: 3 (Close), action: 8224, new_state: 4 (CLOSING)
ofonod[944]: PPP: lcp: pppcp_initialize_restart_count: current state
9:OPENED
ofonod[944]: PPP: lcp: pppcp_send_terminate_request: current state 9:OPENED
ofonod[944]: PPP: ipcp: pppcp_generate_event: current state 9:OPENED
ofonod[944]: PPP: event: 1 (Down), action: 201, new_state: 1 (STARTING)
ofonod[944]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_enter_phase() 5

ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_context_unregister()
0xc10ed0, 0xc10d90
ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_context_remove() atom: 0xc10ef0
ofonod[944]:
../ofono-1.24/drivers/atmodem/gprs-context.c:at_gprs_context_remove()
ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_unregister() 0xc10d90

Terminate request is sent and then gprs-context atom is removed before
Terminate Ack is received.


II/ 0001-PPP-send-escape-sequence-when-ofono-dies.patch

The patch I made to fix the problem. The idea is to immediately send
escape sequence when removing gprs-context atom. This patch is not ready
to be sent (at least it must be split in two patches). Can you tell me
what you think about this patch? 


Best Regards,


Christophe Ronco


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-PPP-send-escape-sequence-when-ofono-dies.patch --]
[-- Type: text/x-patch, Size: 2042 bytes --]

From 124a67db2437b4619bb2a42d7776fa3b1aeab50c Mon Sep 17 00:00:00 2001
From: Christophe Ronco <c.ronco@kerlink.fr>
Date: Thu, 12 Jul 2018 18:04:44 +0200
Subject: [PATCH 1/1] PPP: send escape sequence when ofono dies

When ofono dies while connected using PPP, AT channel is not put back to
command mode.
If ofono is restarted, it won't be able to connect as it gets no answer to
AT commands on this AT channel.
---
 drivers/atmodem/gprs-context.c |  1 +
 gatchat/gatppp.c               | 16 ++++++++++++++++
 gatchat/gatppp.h               |  1 +
 3 files changed, 18 insertions(+)

diff --git a/drivers/atmodem/gprs-context.c b/drivers/atmodem/gprs-context.c
index 42ec556..5761b3c 100644
--- a/drivers/atmodem/gprs-context.c
+++ b/drivers/atmodem/gprs-context.c
@@ -465,6 +465,7 @@ static void at_gprs_context_remove(struct ofono_gprs_context *gc)
 	DBG("");
 
 	if (gcd->state != STATE_IDLE && gcd->ppp) {
+		g_at_ppp_send_escape_sequence(gcd->ppp);
 		g_at_ppp_unref(gcd->ppp);
 		g_at_chat_resume(gcd->chat);
 	}
diff --git a/gatchat/gatppp.c b/gatchat/gatppp.c
index 4a80b4b..dbb99e3 100644
--- a/gatchat/gatppp.c
+++ b/gatchat/gatppp.c
@@ -712,6 +712,22 @@ static gboolean send_escape_sequence(gpointer user_data)
 	return FALSE;
 }
 
+void g_at_ppp_send_escape_sequence(GAtPPP *ppp)
+{
+	GAtIO *io;
+
+	DBG(ppp, "");
+	if (ppp == NULL)
+		return;
+
+	io = g_at_hdlc_get_io(ppp->hdlc);
+
+	if (io == NULL)
+		return;
+
+	g_at_io_write(io, "+++", 3);
+}
+
 void g_at_ppp_suspend(GAtPPP *ppp)
 {
 	if (ppp == NULL)
diff --git a/gatchat/gatppp.h b/gatchat/gatppp.h
index 213f7e9..ffd6879 100644
--- a/gatchat/gatppp.h
+++ b/gatchat/gatppp.h
@@ -69,6 +69,7 @@ void g_at_ppp_set_suspend_function(GAtPPP *ppp, GAtSuspendFunc func,
 					gpointer user_data);
 void g_at_ppp_set_debug(GAtPPP *ppp, GAtDebugFunc func, gpointer user_data);
 void g_at_ppp_shutdown(GAtPPP *ppp);
+void g_at_ppp_send_escape_sequence(GAtPPP *ppp);
 void g_at_ppp_suspend(GAtPPP *ppp);
 void g_at_ppp_resume(GAtPPP *ppp);
 void g_at_ppp_ref(GAtPPP *ppp);
-- 
2.7.4


[-- Attachment #3: reconnectError_01.tar.gz --]
[-- Type: application/gzip, Size: 24583 bytes --]

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

* Re: no connection after ofono restart while huawei modem connected
  2018-07-13  7:47 no connection after ofono restart while huawei modem connected Christophe Ronco
@ 2018-07-13 16:09 ` Denis Kenzior
  2018-07-19 10:40   ` Christophe Ronco
  0 siblings, 1 reply; 8+ messages in thread
From: Denis Kenzior @ 2018-07-13 16:09 UTC (permalink / raw)
  To: ofono

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

Hi Christophe,

On 07/13/2018 02:47 AM, Christophe Ronco wrote:
> Hi,
> 
> I use a Huawei MS2372h-607. It is a classical AT+PPP modem. I have a
> problem when I stop ofono while context is activated. When I restart
> ofono (without unplugging the modem), I am not able to send any AT
> command on Modem channel because this channel is still in data mode.

Interesting.  Isn't AT+CFUN=0 initiated in the modem.disable() driver 
method taking care of taking the port out of data mode?

> 
> I made a patch to send escape sequence when gprs-context atom is
> removed. It fixes the problem but I don't know if this is the right
> thing to do.

The biggest problem with PPP is that it needs some time to work.  When 
ofono is shutting down, the modem driver is the only thing that is 
afforded a grace period.  The atoms & related drivers are removed 
immediately.  Hence the modem driver is the preferred place to handle this.

> 
> Attached to this mail:
> 
> I/ reconnectError_01: traces of complete test (with debug and AT debug).
> Test done:
> 
> 1) board boot
> 
> 2) Connection (success), start at line 1058:
> 
> connmanctl connect cellular...
> 
> 3) stop ofono, start at line 1109:
> 
> /etc/init.d/ofono stop
> 
> 4) start ofono, start at line 1348:
> 
> /etc/init.d/ofono start
> 
> 5) Connection (error), start at line 2018:
> 
> connmanctl connect cellular...
> 
> 
> I don't have PPP debug in this trace but here is what happens at PPP
> level when Ofono is stopped:
> 
> ofonod[944]:
> ../ofono-1.24/drivers/atmodem/gprs-context.c:at_gprs_detach_shutdown() cid 0

This is really just a side-effect of the netreg atom being removed 
first.  See gprs_netreg_removed().  This code path might not even 
actually be triggered in all situations...

> ofonod[944]: PPP: lcp: pppcp_generate_event: current state 9:OPENED
> ofonod[944]: PPP: event: 3 (Close), action: 8224, new_state: 4 (CLOSING)
> ofonod[944]: PPP: lcp: pppcp_initialize_restart_count: current state
> 9:OPENED
> ofonod[944]: PPP: lcp: pppcp_send_terminate_request: current state 9:OPENED
> ofonod[944]: PPP: ipcp: pppcp_generate_event: current state 9:OPENED
> ofonod[944]: PPP: event: 1 (Down), action: 201, new_state: 1 (STARTING)
> ofonod[944]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_enter_phase() 5
> 
> ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_context_unregister()

gprs context is removed right after...

> 0xc10ed0, 0xc10d90
> ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_context_remove() atom: 0xc10ef0
> ofonod[944]:
> ../ofono-1.24/drivers/atmodem/gprs-context.c:at_gprs_context_remove()
> ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_unregister() 0xc10d90
> 
> Terminate request is sent and then gprs-context atom is removed before
> Terminate Ack is received.
> 
> 
> II/ 0001-PPP-send-escape-sequence-when-ofono-dies.patch
> 
> The patch I made to fix the problem. The idea is to immediately send
> escape sequence when removing gprs-context atom. This patch is not ready
> to be sent (at least it must be split in two patches). Can you tell me
> what you think about this patch?
> 

In theory we already have the suspend functionality on GAtPPP (e.g. 
g_at_ppp_suspend).  But I dimly recall some sort of guard timeout must 
be used.  Since PPP is created in the gprs-context driver and it is 
destroyed immediately, this probably doesn't help you.

The best course of action would be to have modem.disable() issue a 
CFUN=0 equivalent that resets everything properly.  If that's not 
possible, then a solution along the lines of what you propose is needed. 
  E.g. sending a '+++' in at_gprs_context_remove if the state isn't IDLE.

Regards,
-Denis

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

* Re: no connection after ofono restart while huawei modem connected
  2018-07-13 16:09 ` Denis Kenzior
@ 2018-07-19 10:40   ` Christophe Ronco
  2018-07-19 16:20     ` Denis Kenzior
  0 siblings, 1 reply; 8+ messages in thread
From: Christophe Ronco @ 2018-07-19 10:40 UTC (permalink / raw)
  To: ofono

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

Hi Denis


On 07/13/2018 06:09 PM, Denis Kenzior wrote:
> Hi Christophe,
>
> On 07/13/2018 02:47 AM, Christophe Ronco wrote:
>> Hi,
>>
>> I use a Huawei MS2372h-607. It is a classical AT+PPP modem. I have a
>> problem when I stop ofono while context is activated. When I restart
>> ofono (without unplugging the modem), I am not able to send any AT
>> command on Modem channel because this channel is still in data mode.
>
> Interesting.  Isn't AT+CFUN=0 initiated in the modem.disable() driver
> method taking care of taking the port out of data mode?
Yes AT+CFUN=0 is sent in huawei_disable function (in the plugin used by
this modem). In traces sent in previous mail, this is done at line 1157.
And modem answers OK to this command.
I didn't know that this command usually put the other channel back to
command mode.
>
>>
>> I made a patch to send escape sequence when gprs-context atom is
>> removed. It fixes the problem but I don't know if this is the right
>> thing to do.
>
> The biggest problem with PPP is that it needs some time to work.  When
> ofono is shutting down, the modem driver is the only thing that is
> afforded a grace period.  The atoms & related drivers are removed
> immediately.  Hence the modem driver is the preferred place to handle
> this.
>
>>
>> Attached to this mail:
>>
>> I/ reconnectError_01: traces of complete test (with debug and AT debug).
>> Test done:
>>
>> 1) board boot
>>
>> 2) Connection (success), start at line 1058:
>>
>> connmanctl connect cellular...
>>
>> 3) stop ofono, start at line 1109:
>>
>> /etc/init.d/ofono stop
>>
>> 4) start ofono, start at line 1348:
>>
>> /etc/init.d/ofono start
>>
>> 5) Connection (error), start at line 2018:
>>
>> connmanctl connect cellular...
>>
>>
>> I don't have PPP debug in this trace but here is what happens at PPP
>> level when Ofono is stopped:
>>
>> ofonod[944]:
>> ../ofono-1.24/drivers/atmodem/gprs-context.c:at_gprs_detach_shutdown()
>> cid 0
>
> This is really just a side-effect of the netreg atom being removed
> first.  See gprs_netreg_removed().  This code path might not even
> actually be triggered in all situations...
>
>> ofonod[944]: PPP: lcp: pppcp_generate_event: current state 9:OPENED
>> ofonod[944]: PPP: event: 3 (Close), action: 8224, new_state: 4 (CLOSING)
>> ofonod[944]: PPP: lcp: pppcp_initialize_restart_count: current state
>> 9:OPENED
>> ofonod[944]: PPP: lcp: pppcp_send_terminate_request: current state
>> 9:OPENED
>> ofonod[944]: PPP: ipcp: pppcp_generate_event: current state 9:OPENED
>> ofonod[944]: PPP: event: 1 (Down), action: 201, new_state: 1 (STARTING)
>> ofonod[944]: PPP: ../ofono-1.24/gatchat/gatppp.c:ppp_enter_phase() 5
>>
>> ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_context_unregister()
>
> gprs context is removed right after...
>
>> 0xc10ed0, 0xc10d90
>> ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_context_remove() atom:
>> 0xc10ef0
>> ofonod[944]:
>> ../ofono-1.24/drivers/atmodem/gprs-context.c:at_gprs_context_remove()
>> ofonod[944]: ../ofono-1.24/src/gprs.c:gprs_unregister() 0xc10d90
>>
>> Terminate request is sent and then gprs-context atom is removed before
>> Terminate Ack is received.
>>
>>
>> II/ 0001-PPP-send-escape-sequence-when-ofono-dies.patch
>>
>> The patch I made to fix the problem. The idea is to immediately send
>> escape sequence when removing gprs-context atom. This patch is not ready
>> to be sent (at least it must be split in two patches). Can you tell me
>> what you think about this patch?
>>
>
> In theory we already have the suspend functionality on GAtPPP (e.g.
> g_at_ppp_suspend).  But I dimly recall some sort of guard timeout must
> be used.  Since PPP is created in the gprs-context driver and it is
> destroyed immediately, this probably doesn't help you.
>
> The best course of action would be to have modem.disable() issue a
> CFUN=0 equivalent that resets everything properly.  If that's not
> possible, then a solution along the lines of what you propose is
> needed.  E.g. sending a '+++' in at_gprs_context_remove if the state
> isn't IDLE.
I don't have a document describing AT command supported by MS2372. I use
a document describing AT command supported by another Huawei modem. I
didn't find any better command than AT+CFUN=0 to try to put back PPP
channel in command mode.
I had a look at g_at_ppp_suspend and you are right, there is a guard
timeout before sending '+++'. That's why it won't solve my problem.
Ofono will die before this command is really sent.
So I don't have any better idea than patch I already sent? Should I send
a proper patch series with similar content?

Best Regards,

Christophe




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

* Re: no connection after ofono restart while huawei modem connected
  2018-07-19 10:40   ` Christophe Ronco
@ 2018-07-19 16:20     ` Denis Kenzior
  2018-07-25 13:43       ` Christophe Ronco
  0 siblings, 1 reply; 8+ messages in thread
From: Denis Kenzior @ 2018-07-19 16:20 UTC (permalink / raw)
  To: ofono

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

Hi Christophe,

>> The best course of action would be to have modem.disable() issue a
>> CFUN=0 equivalent that resets everything properly.  If that's not
>> possible, then a solution along the lines of what you propose is
>> needed.  E.g. sending a '+++' in at_gprs_context_remove if the state
>> isn't IDLE.
> I don't have a document describing AT command supported by MS2372. I use
> a document describing AT command supported by another Huawei modem. I
> didn't find any better command than AT+CFUN=0 to try to put back PPP
> channel in command mode.

Sometimes these modules take an extra reset parameter after the CFUN. 
E.g. AT+CFUN=0,1 to reset the module completely.  Not sure if this has 
other implications.  Possibly we can issue a AT+CFUN=1,1 or AT+CFUN=4,1 
on .enable() that might fix this as well.

> I had a look at g_at_ppp_suspend and you are right, there is a guard
> timeout before sending '+++'. That's why it won't solve my problem.
> Ofono will die before this command is really sent.
> So I don't have any better idea than patch I already sent? Should I send
> a proper patch series with similar content?

That's the issue, the guard timeout is supposed to be used after all 
activity has been stopped and only then should '+++' be sent.  So it 
might be a good idea to put this behind a VENDOR guarded if-statement 
and issue the '+++' directly to the GAtIO without involving GAtPPP at all.

Regards,
-Denis

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

* Re: no connection after ofono restart while huawei modem connected
  2018-07-19 16:20     ` Denis Kenzior
@ 2018-07-25 13:43       ` Christophe Ronco
  2018-07-25 13:45         ` [PATCH 1/2] atmodem: Add gprs-context quirk for HUAWEI vendor Christophe Ronco
  0 siblings, 1 reply; 8+ messages in thread
From: Christophe Ronco @ 2018-07-25 13:43 UTC (permalink / raw)
  To: ofono

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

Hi Denis,


On 07/19/2018 06:20 PM, Denis Kenzior wrote:
> Hi Christophe,
>
>>> The best course of action would be to have modem.disable() issue a
>>> CFUN=0 equivalent that resets everything properly.  If that's not
>>> possible, then a solution along the lines of what you propose is
>>> needed.  E.g. sending a '+++' in at_gprs_context_remove if the state
>>> isn't IDLE.
>> I don't have a document describing AT command supported by MS2372. I use
>> a document describing AT command supported by another Huawei modem. I
>> didn't find any better command than AT+CFUN=0 to try to put back PPP
>> channel in command mode.
>
> Sometimes these modules take an extra reset parameter after the CFUN.
> E.g. AT+CFUN=0,1 to reset the module completely.  Not sure if this has
> other implications.  Possibly we can issue a AT+CFUN=1,1 or
> AT+CFUN=4,1 on .enable() that might fix this as well.
With huawei plugin, we have:
start ofono:
huawei_enable:
AT+CFUN=1
AT+CFUN=5
huawei_set_online:
AT+CFUN=1

stop ofono:
huawei_disable:
AT+CFUN=0

I tried to add reset parameter both in huawei_disable and in
huawei_enable and reproduced the current problem with these changes.
This test was done with a different huawei USB key (E3372).
In traces attached, you will see usual problem and +CFUN like that:
start ofono:
huawei_enable:
Jul 25 07:09:18 klk-lpbs-06029C daemon.info ofonod[2522]: PCUI: >
AT+CFUN=1,1\r
Jul 25 07:09:18 klk-lpbs-06029C daemon.info ofonod[2522]: PCUI: >
AT+CFUN=5\r
huawei_set_online:
Jul 25 07:09:19 klk-lpbs-06029C daemon.info ofonod[2522]: PCUI: >
AT+CFUN=1\r

stop ofono:
huawei_disable:
Jul 25 07:09:53 klk-lpbs-06029C daemon.info ofonod[2522]: PCUI: >
AT+CFUN=0,1\r

restart ofono:
huawei_enable:
Jul 25 07:10:03 klk-lpbs-06029C daemon.info ofonod[2579]: PCUI: >
AT+CFUN=1,1\r
Jul 25 07:10:03 klk-lpbs-06029C daemon.info ofonod[2579]: PCUI: >
AT+CFUN=5\r
huawei_set_online:
Jul 25 07:10:03 klk-lpbs-06029C daemon.info ofonod[2579]: PCUI: >
AT+CFUN=1\r

>
>> I had a look at g_at_ppp_suspend and you are right, there is a guard
>> timeout before sending '+++'. That's why it won't solve my problem.
>> Ofono will die before this command is really sent.
>> So I don't have any better idea than patch I already sent? Should I send
>> a proper patch series with similar content?
>
> That's the issue, the guard timeout is supposed to be used after all
> activity has been stopped and only then should '+++' be sent.  So it
> might be a good idea to put this behind a VENDOR guarded if-statement
> and issue the '+++' directly to the GAtIO without involving GAtPPP at
> all.
Ok for the VENDOR guarded if-statement and the direct call to GAtIO.
Patches follow.

Best regards,

Christophe


[-- Attachment #2: reconnectError_04.tar.gz --]
[-- Type: application/gzip, Size: 14949 bytes --]

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

* [PATCH 1/2] atmodem: Add gprs-context quirk for HUAWEI vendor
  2018-07-25 13:43       ` Christophe Ronco
@ 2018-07-25 13:45         ` Christophe Ronco
  2018-07-25 13:45           ` [PATCH 2/2] huawei: use VENDOR_HUAWEI quirk on gprs context creation Christophe Ronco
  2018-07-25 19:12           ` [PATCH 1/2] atmodem: Add gprs-context quirk for HUAWEI vendor Denis Kenzior
  0 siblings, 2 replies; 8+ messages in thread
From: Christophe Ronco @ 2018-07-25 13:45 UTC (permalink / raw)
  To: ofono

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

When ofono dies while connected using PPP, modem AT channel is not put
back to command mode (tested with HUAWEI modems E3372 and MS2372).
If ofono is restarted, it won't be able to connect as it gets no answer
to AT commands on this AT channel.
This patch adds a quirk to immediately send escape sequence on modem
channel when gprs-context atom is removed.
---
 drivers/atmodem/gprs-context.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/atmodem/gprs-context.c b/drivers/atmodem/gprs-context.c
index 42ec556..79ac4c8 100644
--- a/drivers/atmodem/gprs-context.c
+++ b/drivers/atmodem/gprs-context.c
@@ -461,10 +461,19 @@ static int at_gprs_context_probe(struct ofono_gprs_context *gc,
 static void at_gprs_context_remove(struct ofono_gprs_context *gc)
 {
 	struct gprs_context_data *gcd = ofono_gprs_context_get_data(gc);
+	GAtIO *io;
 
 	DBG("");
 
 	if (gcd->state != STATE_IDLE && gcd->ppp) {
+		if ((gcd->vendor == OFONO_VENDOR_HUAWEI) && gcd->chat) {
+			/* immediately send escape sequence */
+			io = g_at_chat_get_io(gcd->chat);
+
+			if (io)
+				g_at_io_write(io, "+++", 3);
+		}
+
 		g_at_ppp_unref(gcd->ppp);
 		g_at_chat_resume(gcd->chat);
 	}
-- 
2.7.4


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

* [PATCH 2/2] huawei: use VENDOR_HUAWEI quirk on gprs context creation
  2018-07-25 13:45         ` [PATCH 1/2] atmodem: Add gprs-context quirk for HUAWEI vendor Christophe Ronco
@ 2018-07-25 13:45           ` Christophe Ronco
  2018-07-25 19:12           ` [PATCH 1/2] atmodem: Add gprs-context quirk for HUAWEI vendor Denis Kenzior
  1 sibling, 0 replies; 8+ messages in thread
From: Christophe Ronco @ 2018-07-25 13:45 UTC (permalink / raw)
  To: ofono

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

---
 plugins/huawei.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plugins/huawei.c b/plugins/huawei.c
index f02315d..817ee66 100644
--- a/plugins/huawei.c
+++ b/plugins/huawei.c
@@ -875,7 +875,7 @@ static void huawei_post_sim(struct ofono_modem *modem)
 
 		data->gprs = ofono_gprs_create(modem, OFONO_VENDOR_HUAWEI,
 						"atmodem", data->pcui);
-		data->gc = ofono_gprs_context_create(modem, 0,
+		data->gc = ofono_gprs_context_create(modem, OFONO_VENDOR_HUAWEI,
 						"atmodem", data->modem);
 
 		if (data->gprs && data->gc)
-- 
2.7.4


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

* Re: [PATCH 1/2] atmodem: Add gprs-context quirk for HUAWEI vendor
  2018-07-25 13:45         ` [PATCH 1/2] atmodem: Add gprs-context quirk for HUAWEI vendor Christophe Ronco
  2018-07-25 13:45           ` [PATCH 2/2] huawei: use VENDOR_HUAWEI quirk on gprs context creation Christophe Ronco
@ 2018-07-25 19:12           ` Denis Kenzior
  1 sibling, 0 replies; 8+ messages in thread
From: Denis Kenzior @ 2018-07-25 19:12 UTC (permalink / raw)
  To: ofono

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

Hi Christophe,

On 07/25/2018 08:45 AM, Christophe Ronco wrote:
> When ofono dies while connected using PPP, modem AT channel is not put
> back to command mode (tested with HUAWEI modems E3372 and MS2372).
> If ofono is restarted, it won't be able to connect as it gets no answer
> to AT commands on this AT channel.
> This patch adds a quirk to immediately send escape sequence on modem
> channel when gprs-context atom is removed.
> ---
>   drivers/atmodem/gprs-context.c | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 

Both applied, thanks.

Regards,
-Denis


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

end of thread, other threads:[~2018-07-25 19:12 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-13  7:47 no connection after ofono restart while huawei modem connected Christophe Ronco
2018-07-13 16:09 ` Denis Kenzior
2018-07-19 10:40   ` Christophe Ronco
2018-07-19 16:20     ` Denis Kenzior
2018-07-25 13:43       ` Christophe Ronco
2018-07-25 13:45         ` [PATCH 1/2] atmodem: Add gprs-context quirk for HUAWEI vendor Christophe Ronco
2018-07-25 13:45           ` [PATCH 2/2] huawei: use VENDOR_HUAWEI quirk on gprs context creation Christophe Ronco
2018-07-25 19:12           ` [PATCH 1/2] atmodem: Add gprs-context quirk for HUAWEI vendor Denis Kenzior

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.