Open aleksander0m opened 2 years ago
jow in IRC suggested we launch some simple dummy monitor process, e.g. from the modemmanager protocol handler. This process could trap TERM signals, so that we explicitly disconnect the associated modem in modemmanager if netifd gets killed or crashes. This would solve the first issue listed in the description.
For the second one, I guess we could update the ModemManager init script so that upon boot it makes sure all interfaces with protocol "modemmanager" get reported as down by default, something like that.
Open to suggestions on how to handle all this.
@nickberry17 FYI
Send a merge request upstream to the ModemManager repository that adds the monitor process suggest by @jow and implemented by @dangowrt https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1131
There are two main situations that would lead to an interface with protocol "modemmanager" managed in netfid getting out of sync with respect to the associated modem object state in ModemManager:
If netifd crashes or gets killed there won't be a clean ifdown procedure done for each interface. In this case, an interface that was reportedly "up" in netifd before the crash will end up reported "down" once netifd restarts, while the state of the modem in ModemManager doesn't change from "connected".
If ModemManager crashes or gets killed, there won't be any notification to netifd that the modem got disconnected, so the state of the modem in ModemManager would not be "connected" any more, while the network interface status in netifd would still be "up".
We should somehow bind the state of both processes, so that abrupt crashes of any of them don't make them get out of sync completely.