Yeah there is clearly huge demand for these changes and so efforts to improve are hugely welcome.
Hi !
I've improved the qmi scripts for our usage. The code is really bad but it gave me a high stability and also muxing and packet aggregation. Perhaps you can use it for inspiration:
1 Like
Thanks for sharing. Does this include reconnection handling and if so how is that implemented? As you can see from the above there is a desire to avoid polling and instead react to modem events as soon as they happen, which requires some special handling to keep the possibility to run manual commands whilst the connection watchdog is running.
There's a watchdog implemented which checks the connection status. It also has some advanced checks to see if
- PDP context is still active and if
- traffic is flowing, if the modem or the provider forget the PDP contexts (don't ask, I know this from big global m2m providers)
- counts critical qmi errors
The watchdog is started for every qmi connection and handled by netifd, so the common netifd process flow works.
Every qmi call goes thru timeout and locking to make sure that [parallelism] is not a problem.
Also it is important for stability that you register client ids for the several qmi services and only use them later. A special case is the WDS service where a new client id is bound to the PDP context.
If you do not care, the modem may hang up. This is done through a hotplug script which also intializes the modem and creates the several muxes which are needed for packet aggregation (speed, speed).
That's also the reason for the hotplug script. If the modem reboots because it is unreliable, you have to make sure it is correctly initialized again.
Currently it needs qmicli and uqmi, so it has big dependencies. Also it calls somewhere a usb-repower shell script, which turns USB power off/on to reboot it in cause auf catastrophic failure. But that's not included.
1 Like
Sounds pretty comprehensive. I haven't looked in detail at the code, but isn't the watchdog relying upon polling every sixty seconds?
At the moment ModemManager interprets disconnects from the modem as they come in and can react accordingly. And yet presently it just informs netifd of the disconnect, doesn't reconnect, because the author expects netifd to handle the reconnection, and because netifd does not act on the disconnect, the net result (no pun intended!) is loss of internet connectivity for the user.
So even though the ModemManager implementation in OpenWrt is broken, at least it is configured to react immediately without polling.
It polls every 60 seconds, correct. But only relying on the disconnect events will not be enough to make sure you have a reliable connection. I recommend to check data counters also, if you want it to be long term stable.
So to summarize in the ideal case there'd be:
- continuous monitoring for disconnect events
- periodic evaluation of data transfer
Anything else?
I would also monitor critical QMI commands. If the failure count exceeds a limit, I would recommend reset action:
- Use qmi to reset the device (dms-set-operating-mode=reset) if it is accepted or
- a hook-script for USB power flush (generic alternative: reboot the router)
I'm just thinking of a openwrt based router far away from home without an easy way to reach it, or some M2M monitoring devices in the field.
1 Like
I presume this would have to be used with caution incase somehow the code leads to very frequent power cycles?
Hi @avalentin 
That's huge! It's a big addition to what is planned here though I'm not sure all of it is mergeable as is.
I would try to go step by step and start with the least controversial changes first.
Your mentions of strange behaviour of providers and modems requiring special handling sound too familiar to me.
I also think the ability to manage remote devices is a good measure. The router I use for developing is 700km away from me.
I also learned the hard way that power-cycling the modem is sometimes necessary (though very rarely so) but it's also very intrusive and I'm not sure it should be part of the protocol handler. The means for cycling power can be very different. On the Dual-Q H721, there's a gpio. Linux can't do much in terms of standard interfaces. I'd say it's to early for that in Openwrt.
1 Like
Of course, that should not happen after one simple failure!
Don't misunderstand. I really appreciate your idea of some kind of daemon.
All this stuff can be added later. It just wanted give you an idea what all could go wrong.
Happy coding!
All good - no misunderstanding 
The daemon is mainly for logistics and your changes add a lot of logic.
just wanted to say that i haven't given up yet
there's stuff going on in my life and at work that need a lot of my attention.
the first phase is getting the ubus server up to cover all existing functionality.
i've started with a method that allows ubus clients to send the binary payload directly.
re-implementing every qmi call is too time-consuming and would blow up the binary size.
really, i want to put parameters passed via ubus through a unified parser that would also handle the command line arguments but that is only loud thinking at the moment.
when that is up, it should be possible to synchronize uqmi calls by spawning the daemon-like using netifd and freezing uqmi instances should be a thing of the past.
i'm unsure whether the extdev interface is suitable for that.
as far as i can see, there would have to be a uqmi-device-service that 'creates' uqmi devices.
is there any public implementation of a netifd device type using extdev?
the 'react to device logic' is the last step in that plan. i'm tempted to do it first but it doesn't really make sense, imo.
2 Likes
Still on the cards?
yes - but uqmi went down the list of my priorities - sady 
some regulation has changed at my uni and i actually do need to finish my studies soonish 
to avoid being kicked out.
the work project that synergized well with working on uqmi was replaced with a mesh project.
a few hours of the week are still dedicated to uqmi and i submitted an unrelated patch just now. i just can't put in as much as i'd hoped.
1 Like
@yogo1212 please do not spend any time on this that might interfere with your studies. Those few hours you spend on uqmi should perhaps be diverted to studies if there is a danger of losing your place. My best wishes to you for your continued studies, which must take absolute priority.
Looks like I won't have much time to spare until May :-/
This is still on my radar
1 Like
I've was lucky enough to be able to talk with lynxis about this and, if everything works out, he will have a look into it 
2 Likes
I am also available as a tester for WWAN (but unfortunately not QMI) improvements.
Hardware:
- Huawei E3372h LTE modem reflashed to stick firmware - supports NCM
- Alfa Network AUCM5G-T700 5G modem - to arrive on Monday, supports MBIM