| Commit message (Collapse) | Author | Age |
|---|
| |\
| |
| | |
modemmanager: reconnect interface if the modemmanager detects a disconnect
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are situation for mobile routers, that the modemmanager can not
stay connected to the mobile network. There can have various reasons.
In order for the system to reconnect automatically, the netifd must be
informed that it must re-establish the connection.
The modem manager already does have a script callback handling which is
already used by the modemmanager in openwrt. Currently the modem is marked
as not unavailable when a disconnected event is detected.
The behavior was changed with this commit, so that a reconnect of the
interface is now triggerd via the netifd if the modem disconnects.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
|
| |/
|
|
|
|
|
|
|
|
| |
Virtual netdevices created for multiplexing should not be skipped
when reporting events, otherwise it is not possible to setup the
data connection.
Add these exceptions in mm_report_event function.
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
|
| |
|
|
|
|
|
|
| |
Moving the openwrt related files to subdirectories as they are installed
on the system. This change makes it immediately apparent during development
where the file is to be installed in the running system.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
service
Before this change, the status of the sysfs paths from the kernel events
was cached with a cache file. This is necessary to mark configured modems
as available for the netifd.
Using the new monitor service via the mmcli command 'mmcli -M' simplifies
the whole process. There is no need to start sub shells in the background
anymore that monitors whether the modem has already been added to the
ModemManager.
For this purpose, a new service was added that reacts on add and remove
events for modems in the ModemManager and, if necessary, marks the logical
netifd interface as available.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
|
| |
|
|
|
|
|
| |
It is usual that the includes are listed at the beginning of the script.
So let's do it that way too.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
|
| |
|
|
|
|
|
|
|
|
| |
If the ModemManager process crashes, the interfaces are not cleaned
up properly because the stop_service method is not called. With this
change, the interfaces are cleaned up both when stopping the service
and during a crash. Therefore it is no longer necessary to perform a
cleanup at the beginning.
Signed-off-by: Oliver Sedlbauer <osedlbauer@tdt.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When ModemManager is started on boot we may end up with hotplug events
reported directly to the daemon, plus some others already cached in
the cache file before the daemon was started.
If the cached events correspond to the same device that is still
notifying ports directly, we may end up with a modem object created
before the cached events have been emitted, so the modem may not
handle all control/data ports it should.
E.g.:
- modem detected
- hotplug event for wwan0 port, cached as MM not running
- hotplug event for cdc-wdm0 port, cached as MM not running
- hotplug event for ttyUSB0, cached as MM not running
- MM starts
- hotplug event for ttyUSB1, directly processed as MM is running
- hotplug event for ttyUSB2, directly processed as MM is running
- modem object created with ttyUSB1 and ttyUSB2
- 2s after MM starts, cached events for wwan0, cdc-wdm0 and ttyUSB0
happen, but are ignored because the modem object has already been
created
MM expects that ports of the same device are reported with less than
1500ms in between ports. In other words, if ports are reported more
than 1500ms after the last reported port, they may get ignored.
If we remove the 2s timeout, the report of the cached events will
happen as soon as MM starts, which makes it much more likely to happen
in the timeslot that MM expects for ports of the same device reported.
The logic is still not perfect, and we may also need to increase that
1500ms timeout inside MM, but removing the 2s timeout right away here
makes sense.
This 2s timeout was introduced along with the new wrapper launcher for
the daemon, it didn't exist before.
Signed-off-by: Aleksander Morgado <aleksander@aleksander.es>
|
|
|
The way the init script is written now, we get a bad output when calling
the ubus service backend.
ubus call service list "{'verbose':true,'name':'modemmanager'}"
>{
> "modemmanager": {
> "instances": {
> "instance1": {
> "running": true,
> "pid": 20511,
> "command": [
> "sh",
> "-c",
> ".
>/usr/share/ModemManager/modemmanager.common; \t
>mkdir -m 0755 -p /var/run/modemmanager; \t
>mm_cleanup_interfaces; \t
>( mm_report_events_from_cache ) >/dev/null 2>&1 & \t
>/usr/sbin/ModemManager"
> ],
> "term_timeout": 5,
> "respawn": {
> "threshold": 3600,
> "timeout": 5,
> "retry": 5
> },
> "pidfile":"/var/run/modemmanager/modemmanager.pid"
> }
> }
> }
>}"
I also get the output in the log that the PID file cannot be created.
> daemon.err procd: Failed to remove pidfile: :No such file or directory
The changes in this commit fixes this issues, by moving startup into a
wrapper script.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
|