![[RSS]](./theme/image/rss.png)
For fairly silly reasons I would like to do voice calls using a Sierra Wireless EM7345 4G LTE wireless modem built into a Lenovo Thinkpad X240. However, I am stuck between a lack of documentation and the horrors of proprietary firmware blobs to the extent that I am even unsure whether that's possible without reprogramming the whole device. If you can help me, I'd appreciate any sort of hand-holding. If you think you know someone who might be able to help me, I'd appreciate if you pointed them to this post.
The analog stuff
What works nicely is calling voice numbers. After a minicom -D /dev/ttyACM0, I can do:
AT DT 062210000000 NO CARRIER AT DT 062210000000; OK NO CARRIER
The first command is attempting a data connection that fails because it's a real telephone at the other end. The semicolon in the second command says “do voice“. It actually makes the remote phone ring a few seconds after the modem said OK. I can pick up the call on that remote phone, too, but fairly unsurprisingly there is just silence at the computer and, and whatever I say at either end goes nowhere. The eventual NO CARRIER is when I hang up the phone.
The other way round works as well: seeing the good old RING and typing ATA like in the good old days warmed my heart. Hanging up with an ATH was fun, too. But when no sound is being transported through the Sierra card, these games quickly become boring.
As usual for entities like Sierra, they don't give their documentation to just anyone (as in „me”). I still happen to have a PDF titled „MP 700 Series GPS Rugged Wireless Modem AT Command Reference”, which pertains to some different but reasonably similar device. There, it says:
If your account allows for it, you can attach a headset to your modem and use it as a mobile phone. You require a 4-wire headset with a 2.5 mm connector, to use your modem as a phone. (This plugs into the Audio connector on the back of the modem. You may need an extension cable if the modem is installed in the trunk. Contact your service provider to determine what extension cables are supported.)
Well… The small EM 7345 certainly does not have a 2.5 mm connector. There aren't even soldering pads visible without peeling off stickers:
The Sierra modem as fitted into a Lenovo X240: Certainly no 2.5 mm connectors visible.
There is also no trace of the Sierra card in the ALSA mixer, and neither is there an ALSA card they could have put in as a USB audio device. Hence, at this point I believe getting out some sort of analog-ish audio is unrealistic.
Go digital
However, what if I could pull PCM bytes or perhaps GSM-encoded audio from the device in some way? A thread in the Sierra forum seems to indicate it could work but then trails off into mumbling about firmware versions. Some further mindless typing into search engines suggested to me that the a “version 6“ of the firmware should be able to do PCM voice (in some way not discussed in useful detail). Version 6 sounds a bit menacing to me in that my device says:
at+GMR V1.1,00
I faintly remember having once tried to update the firmware and eventually giving up after some quality time with WINE. On that background, skipping five major versions sounds particularly daring („the Evel Knievel upgrade: what could possibly go wrong except 40 to 50 broken bones“). But then Sierra's support page doesn't even acknowledge the 7345's existence any more.
While Sierra itself does not give its documentation to the unwashed masses, on some more or less shady page I found documentation on the AT commands of one of its the successors, the EM7355. That appears to have a lot of PCM-related commands. In particular:
Note: To enable audio on an audio-capable device, use the “ISVOICEN” customization for AT!CUSTOM (see page 32 for details).
Regrettably, on my box:
AT !CUSTOM ISVOICEEN=1 ERROR
Actually, it would seem that none of the various Sierra-proprietary AT commands starting with a bang are present in my firmware.
That's where I stand. Does anyone have deeper insights into whether I could have GSM voice calls on that board without reverse-engineering the whole firmware?
A tale of two cards
In case you are wondering why I would even want to do GSM telephony with my computer… Well, I have a 4.99 Euro/month 1 GB+telephony flatrate with Winsim (turn off Javascript to avoid their broken cookie banner). While I can recommend Winsim for a telephone support far better than you'd expect for that price (of course: the network coverage isn't great, it's just a Telefonica reseller, and forget about using the e-mail support), they'll charge you another five Euro or so monthly for a second SIM card in that plan, whereas you can get a SIM card for free if you get a second pre-payed contract.
I'm not sure what reasoning is behind two contracts with two cards being cheaper than one contract with two cards, but then telephony prices stopped making any sense a long time ago.
Since my phone can only do UMTS and GSM (i.e., only GSM these days in Germany) and I have the LTE modem inside the computer anyway, I recently transferred the SIM with the flatrate into the LTE modem so my garden office has a faster internet connection than when I'm using the phone as a modem. Consequenly, I now have another (pre-paid) card in the phone. The net effect is that I could do telephone calls for free on the computer if I could just figure out the audio part – whereas naive VoIP doesn't really work in much of the network because of packet loss, latencies, low bandwitdth and so on – and I pay 9 ct per minute for GSM telephony on the phone.
I give you that's probably not a sufficient reason to sink hours of research into the stupid Sierra card. But I'd also have the BIGGEST PHONE ON THE WHOLE TRAIN if I just could pull it off!
Nachtrag (2023-06-21)
Well, on the “new firmware“ part, I found https://lists.freedesktop.org/archives/libqmi-devel/2018-August/002951.html. And oh my, of course Intel don't publish the sources to their firmware flash thingy. That's extremely bad for me because they don't bother to build i386 binaries and now I have to dual-arch in half a linux system:
ldd /opt/intel/platformflashtoollite/bin/platformflashtoollite
linux-vdso.so.1 (0x00007ffcf43ed000)
libdldrapi.so => /opt/intel/platformflashtoollite/lib/libdldrapi.so (0x00007f61d4000000)
libCore.so => /opt/intel/platformflashtoollite/lib/libCore.so (0x00007f61d3c00000)
libNetwork.so => /opt/intel/platformflashtoollite/lib/libNetwork.so (0x00007f61d3800000)
libDeviceManager.so => /opt/intel/platformflashtoollite/lib/libDeviceManager.so (0x00007f61d3400000)
libLogger.so => /opt/intel/platformflashtoollite/lib/libLogger.so (0x00007f61d3000000)
libJson.so => /opt/intel/platformflashtoollite/lib/libJson.so (0x00007f61d2c00000)
libDldrManager.so => /opt/intel/platformflashtoollite/lib/libDldrManager.so (0x00007f61d2800000)
libUtilityWidgets.so => /opt/intel/platformflashtoollite/lib/libUtilityWidgets.so (0x00007f61d2400000)
libQt5Xml.so.5 => /opt/intel/platformflashtoollite/lib/libQt5Xml.so.5 (0x00007f61d2000000)
libQt5Widgets.so.5 => /opt/intel/platformflashtoollite/lib/libQt5Widgets.so.5 (0x00007f61d1600000)
libQt5Gui.so.5 => /opt/intel/platformflashtoollite/lib/libQt5Gui.so.5 (0x00007f61d0c00000)
libQt5Network.so.5 => /opt/intel/platformflashtoollite/lib/libQt5Network.so.5 (0x00007f61d0800000)
libQt5Script.so.5 => /opt/intel/platformflashtoollite/lib/libQt5Script.so.5 (0x00007f61d0200000)
libxfstk-dldr-api.so => /opt/intel/platformflashtoollite/lib/libxfstk-dldr-api.so (0x00007f61cfe00000)
libPlatformUtils.so => /opt/intel/platformflashtoollite/lib/libPlatformUtils.so (0x00007f61cfa00000)
libQt5Core.so.5 => /opt/intel/platformflashtoollite/lib/libQt5Core.so.5 (0x00007f61cf200000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f61d3ebc000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f61d4530000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f61d322c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f61d450c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f61d4502000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f61d44fc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f61d457b000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f61d2e33000)
libUSBScan.so => /opt/intel/platformflashtoollite/lib/libUSBScan.so (0x00007f61cee00000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f61d44a0000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f61d449b000)
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f61d3ad1000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f61d4486000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f61d36bd000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f61d3e35000)
libusb-0.1.so.4 => /lib/x86_64-linux-gnu/libusb-0.1.so.4 (0x00007f61cea00000)
libboost_program_options.so.1.46.1 => /opt/intel/platformflashtoollite/lib/libboost_program_options.so.1.46.1 (0x00007f61ce600000)
libicui18n.so.54 => /opt/intel/platformflashtoollite/lib/libicui18n.so.54 (0x00007f61ce000000)
libicuuc.so.54 => /opt/intel/platformflashtoollite/lib/libicuuc.so.54 (0x00007f61cdc00000)
libicudata.so.54 => /opt/intel/platformflashtoollite/lib/libicudata.so.54 (0x00007f61cc000000)
libudev.so.0 => /usr/lib/x86_64-linux-gnu/libudev.so.0 (0x00007f61d447d000)
libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x00007f61d4471000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f61d3a5e000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f61d4444000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f61d2b48000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f61d3689000)
libudev.so.1 => /usr/lib/x86_64-linux-gnu/libudev.so.1 (0x00007f61d3e0d000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f61d443f000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f61cbc00000)
libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f61d4426000)
libmd.so.0 => /usr/lib/x86_64-linux-gnu/libmd.so.0 (0x00007f61d3a51000)
That's the dependencies even for the CLI version (which, admittedly, calls the same binary). Why does software provided by hardware vendors always have to suck?
But then don't even try this. I was going to write: „The actual flash procedure takes a surprisingly long time (minutes) of 100% CPU“. Well, if it hadn't gone into a tight loop, it would have taken just a few seconds as per the log published on the page above, but regrettably it did just that, go into a tight loop. Perhaps I should have been more careful and installe a 64-bit gdb, too. In reality I just broke out after about 30 minutes, and really, I don't think I could have done much good with the debugger and without any source.
The consequence: The card is bricked; at boot time, it causes USB timeouts, and of course it never appears on the bus. I'm now cutting my losses. I have wasted far too much time on that thing. Plan B: find some discarded phone that can do LTE but isn't controlled by either Apple or Google and use that as a modem. At least there's no issue with voice on such a thing.
Just why does commercial software always have to suck?
Zitiert in: Vom „Humboldt Forum“ nach Knossos: Viel Fantasie über Palastruinen Taming an LTE card in Linux