On Mon, 26 Apr 2021, Alberto Bursi wrote:
Date: Mon, 26 Apr 2021 21:58:23
From: Alberto Bursi <[email protected]>
To: [email protected]
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 <[email protected]>
To: Etienne Champetier <[email protected]>
Cc: Rosen Penev <[email protected]>,
OpenWrt Development List <[email protected]>
Subject: Re: Brokenness of the OpenWrt "packages" repo
Etienne Champetier <[email protected]> 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
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
