Brokenness of the OpenWrt "packages" repo

Tue Apr 27 10:35:56 BST 2021

On Mon, 26 Apr 2021, Alberto Bursi wrote:

> Date: Mon, 26 Apr 2021 21:58:23
> From: Alberto Bursi <bobafetthotmail at gmail.com>
> To: openwrt-devel at lists.openwrt.org
> Subject: Re: Brokenness of the OpenWrt "packages" repo
> 
>
>
> On 26/04/21 16:01, Daniel Golle wrote:
>> On Mon, Apr 26, 2021 at 03:28:22PM +0200, Enrico Mioso wrote:
>>> ... I know you won't like this. But in the end, I guess D-Bus, glib2 and 
> in the end all of MM dependencies will have to be incorporated in the core.
>>>
>>> A stac, of big big software, I know. But supporting 4G/5G in the end will 
> required that.
>> 
>> ModemManager is not the only way to use 4G/5G modems. You can use
>> umbim or uqmi for most tasks. 
>
> In my experience their ability to handle device-specific bugs or "perks" 
> is limited, unless your modem is 100% perfect and never crashes ever and 
> can actually handle the autoreconnect on its own, you will end up in 
> situations where you need to just set up a script that pings Google and 
> reboots the router if network fails.
>
> They also don's support a lot of new LTE features like band lock, band 
> aggregation and more, they are way too simple. I have bought a consumer 
> modem/router that is like 3 times faster while using the same type of 
> CAT6 modem due to band aggregation and the reconnect sequence if the 
> connection drops is very fast because I have set the only 2 LTE bands it 
> can use.
>
> MM is so much better than that. But my main issue with MM is that both 
> maintainers (package and upstream MM maintainers) have not found a way 
> to integrate it well enough with OpenWrt's internals so that when the 
> modem disconnects there is nothing that notices this issue and nothing 
> that reacts to it. So I had to cobble together a script to do this 
> missing link, but it's far from a decent solution. (see the issue thread 
> I opened about this)

That's why in the end, admittedly for different reasons, we ended up writing our own software to do so.
It included an ubus script that tried to match MM bearers with network configurations. In the end it somewhat works, but the integration layer between MM and openwrt is still little bit fragile.
It was enough to add a WireGuard interface to the system to stop MM from starting up. Setting the interface to not auto-start was enough to fix the isue.
If you know me, you know I try to avoid absolute statements in general, and I absolutely don't mean to criticise other people's work here.
The problem is the 5G modems out there are simply too complex to be handled e.g.: statelessly.
I don't like to have this big stack of software on my devices as well, but there are times where you need to compromise. Once it was enough to use AT commands by hand, now its not the case anymore, at least for modern QMI-based modems.
Bring in the multi-bearer dual-stack scenario and you have such a complexity growth...

In general, uqmi and umbim are extremely clean and well-done. I estimate all of you a lot folks. But modems' firmware is a strange world. :)

If you're under the impression a 5G modem might be an over-complicated gigantic piece of software / hardware complexity, I would second you.
That requires scaling of complexity in the host side as well.
Sudden resets and other characteristics, lets you having to be careful to stay consistent with modem state even when MM is behind you, doing it's great amount of work.
This time it's not useless complexity. But well yes - it's a lot of complexity.
Trying to trust the Modem firmware to do things like auto-connecting is very smart and appropriate - if you knw it's going to work. but we're going to face lots of different hardware with different bugs.
So unfortunately we should handle all of them.

>
> Hence why I eventually bought an actual self-contained modem with web 
> interface and all, it's just so much better speed and is less painful to 
> use.
>
> -Alberto
>
>
> Both projects are straight forward, well
>> documented code, easy to extend in case you miss anything.
>> Depending on half of the Freedesktop universe in order to initialize
>> a network interface or receive an SMS in a very complicated way doesn't
>> feel justified to me.
>> 
>> 
>>>
>>> On Mon, 26 Apr 2021, Bjørn Mork wrote:
>>>
>>>> Date: Mon, 26 Apr 2021 07:51:51
>>>> From: Bjørn Mork <bjorn at mork.no>
>>>> To: Etienne Champetier <champetier.etienne at gmail.com>
>>>> Cc: Rosen Penev <rosenp at gmail.com>,
>>>>      OpenWrt Development List <openwrt-devel at lists.openwrt.org>
>>>> Subject: Re: Brokenness of the OpenWrt "packages" repo
>>>>
>>>> Etienne Champetier <champetier.etienne at gmail.com> writes:
>>>>
>>>>> Are you trying at the same time to complain about not run-tested
>>>>> updates and possibly having packages not up to date ?
>>>>
>>>> No.  The package was fine before the version was changed.  In fact, it
>>>> was in much better shape before it was changed to a development version
>>>> by the very same non-maintainer.
>>>>
>>>> If you don't care enough to even install the package, then please don't
>>>> touch the package.
>>>>
>>>>> I would personally mark it as broken or remove it instead of making it
>>>>> work again, but it means removing some other packages.
>>>>
>>>> I'd be all for that, if you apply that rule to all the unmaintained
>>>> packages in the repo.  It's a much better solution than having the repo
>>>> full of arbitrary untested changes to unmaintained packages.
>>>>
>>>> Wrt dbus I'm pretty sure it would provoke an adoption.  There are
>>>> multiple packages depending on it, and as the immediate reports tell
>>>> you:  This particualr umaintained package is in active use.
>>>>
>>>>
>>>>
>>>> Bjørn
>>>>
>>>> _______________________________________________
>>>> openwrt-devel mailing list
>>>> openwrt-devel at lists.openwrt.org
>>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> 
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> 
>> 
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>> 
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>