Deleting a bearer that is still connected

[Aleksander Morgado]

On Mon, Mar 9, 2015 at 9:31 PM, Osborne, Paul <Paul.Osborne at etherios.com> wrote:
> I recently ran into an issue with ModemManager (1.4.4) where I created
> and connected to a bearer and deleted it without first disconnecting.
> I am using a Cinterion PHS8 with two AT ports.  If I delete the bearer
> without first disconnecting, the second AT port (on which I was using
> pppd) is no longer used by ModemManager as the modem is marked as
> forced close.
>
> The issue is easily reproduced by executing the following set of
> commands with ModemManager running with a modem with 2 AT ports found
> by ModemManager:
>
>     mmcli -m 0 -e
>     mmcli -m 0 --create-bearer='apn="myapn"'
>     mmcli -b 0 --connect
>     mmcli -m 0 --delete-bearer=0
>     mmcli -m 0 --create-bearer='apn="myapn"'
>     mmcli -b 1 --connect
>
> On connecting to bearer 1, the following error is received:
>
>     Couldn't connect: cannot keep data port open.Could not open \
>     serial device ttyUSB3: it has been forced close;
>
> The workaround is pretty straightforward, which is to always
> ensure that the bearer is disconnected prior to being removed.  I
> figured I would provide this info to the list as this seemed like a
> potential bug where MM was not properly cleaning up when removing
> the bearer.
>
> The force close appears to occur as a result of
> iochannel_input_availble being executed as a result of a hangup
> initiated by ModemManager itself:
>
>    ModemManager[3052]: <debug> [1425505651.367703] \
>      [mm-port-serial.c:889] common_input_available(): (ttyUSB3) \
>      unexpected port hangup!
>    ModemManager[3052]: <debug> [1425505651.367854] \
>      [mm-port-serial.c:1421] port_serial_close_force(): (ttyUSB3) \
>      forced to close port

Looks like the bearer deletion ends up triggering a disconnect while
pppd is still owning the port. The unexpected port hangup should only
happen when the port gets removed; otherwise it means that we got a
hungup and CLOCAL wasn't set in the port (i.e. pppd was handling it).

Thanks for reporting; added to bugzilla already:
https://bugs.freedesktop.org/show_bug.cgi?id=89512


-- 
Aleksander
https://aleksander.es