ModemManager auto reconnect

[Brendan Simon (eTRIX)]

On 10/02/2016 3:39 AM, Dan Williams wrote:
> On Tue, 2016-02-09 at 11:27 +1100, Brendan Simon (eTRIX) wrote:
>> On 9/02/2016 9:08 AM, Dan Williams wrote:
>>> On Tue, 2016-02-09 at 07:31 +1100, Brendan Simon (eTRIX) wrote:
>>>> I have a number or remotely deployed arm embedded linux systems
>>>> that
>>>> uses a 3G modem via USB to post http information once per second.
>>>>  The
>>>> modem goes down from time to time.  One reason is we assert the
>>>> power
>>>> reset line on the modem once a day (as I've been told that the
>>>> modems
>>>> need to be reset periodically, otherwise functionality degrades
>>>> or
>>>> eventually lost).  The other reasons I am not sure of (service
>>>> provider
>>>> initiated?  bugs in the application code?
>>>>
>>>> The modem can be off for many hours before eventually
>>>> reconnecting
>>>> (possibly by watchdog reboot) which is not acceptable for our
>>>> real
>>>> -time
>>>> monitoring application.
>>>>
>>>> Does MM automatically try to re-establish a connection if it sees
>>>> the
>>>> connection go down, or the modem is reset?
>>>>
>>>> Are there recommended or suggested MM settings such that MM will
>>>> continually try to reconnect if the modem goes down then back up?
>>> This is left up to the connection manager that controls
>>> ModemManager
>>> and tells it to connect.  So whatever you're using to tell
>>> ModemManager
>>> to start the data connection, that's the thing that would monitor
>>> for
>>> the modem being disconnected and periodically restart the data
>>> connection.
>> I created a NetworkManager broadband connection in a Debian virtual
>> machine with a modem connected (dev kit).  I then copied the file
>> that
>> was created
>> (/etc/NetworkManager/system-connections/telstra-mobile-broadband-1)
>> into
>> my build system which will populate my target rootfs for the embedded
>> system.
>>
>> I found that the modem was not coming up at boot, but would come up
>> if I
>> used the `nmtui-connect` utility to activate the connection.  A
>> systemd
>> service was created to bring up the modem at boot time (a one-shot
>> script, which brings the modem down then up then calls `nmcli d
>> connect
>> cdc-wdm0`).
>>
>> The scirpt works but I'm not sure if it's the `right way` to get the
>> modem up automatically.  One interesting thing which may be a clue is
>> that the modem connection does not appear in the `nmtui-edit`
>> utility,
>> but does appear in the `nmtui-connect` utility.  Is this expected ? 
>> Also the LAN connection shows up in both utilities but there a
>> connection file does not exist in /etc/NetworkManager/system
>> -connections/
>>
>> I presume NetworkManager is starting and managing the connection,
>> yes? 
>> How do I get it to auto-reconnect when the connection goes down or is
>> not available?  We are looking at running a custom script invoked via
>> cron every minute, but that seems a bit hacky.
> What version of NM?  There have been improvements to the autoconnect
> logic for WWAN recently in NM, especially if the SIM has a PIN enabled.
>  Aside from bugs, we would expect NM to periodically retry the
> connection if it fails.

The following Debian Jessie packages are installed.
    network-manager                0.9.10.0-7
    modemmanager                   1.4.0-1  

There is no PIN enabled on the SIM cards.

I suspect that there is something not configured properly with NM as it
doesn't recognise that I have a broadband connection if I invoke
`nmtui-edit`.  However it does know about the connection if I invoke
`nmtui-connect`.

Is the file in /etc/NetworkManager/system-connections/ all that I need,
or is there another NM config file that needs to know about the connection?

Is the `uuid` field in the connections file significant?
Does it need to match something on my system?
The `uuid` field is set to the same on all the boxes.

Thanks, Brendan.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20160210/c807c173/attachment.html>