// sorry, re-sending to the group
Hi Aleksander,
2017-06-28 17:20 GMT+02:00 Aleksander Morgado :
> The key point is the kind of error to consider the action fatal and
> abort right away. If the device is removed, we should definitely take
> it as a fatal error and abort
On Wed, Jun 28, 2017 at 4:42 PM, Piotr Figiel wrote:
>
> diff --git a/src/mm-broadband-bearer.c b/src/mm-broadband-bearer.c
> index aeff2ef..db38970 100644
> --- a/src/mm-broadband-bearer.c
> +++ b/src/mm-broadband-bearer.c
> @@ -1586,8 +1586,10 @@ cgact_ready (MMBaseModem
Hi Aleksander, Piotr,> I'm checking the logs and if my understanding is correct it looks like> some logic from bearer disconnect from the connection before the modem> reset happens still executes after modem was lost and when "new" modem> is probed, it looks like it may get in the way of AT ports
On Wed, Jun 28, 2017 at 10:54 AM, Piotr Figiel wrote:
> thanks for reply.
> Yes I could but I think it races with NM which tries to reestablish
> connection, not sure if such testcase will help to debug this.
> I've done some checks with with nmcli d disconnect ttyACM0 and it
Hi Aleksander,
thanks for reply.
Yes I could but I think it races with NM which tries to reestablish
connection, not sure if such testcase will help to debug this.
I've done some checks with with nmcli d disconnect ttyACM0 and it
improved (though I'll redo this more systematically), but the
On Wed, Jun 28, 2017 at 10:27 AM, Piotr Figiel wrote:
> I'm debugging it now but hints would be appreciated.
Can you retry but before running the reset operation, do an explicit
disconnection and/or disable?
E.g.
mmcli --simple-disconnect
mmcli --disable
mmcli --reset