Re: FM350-GL (installed in ThinkPad P1 Gen 5)
Problem solved. Just submitted a MR [1] for the unlock script. Thanks, Thilo [1] https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/1091 On Sun, Nov 5, 2023 at 12:02 AM Thilo-Alexander Ginkel wrote: > Hello again, > > I got a prototype working that successfully unlocks my modem via > /dev/wwan0at0. Currently I have that device name hardcoded. Is there a way > to infer it from the mbim device name? > > Thanks, > Thilo >
Re: FM350-GL (installed in ThinkPad P1 Gen 5)
Hello again, I got a prototype working that successfully unlocks my modem via /dev/wwan0at0. Currently I have that device name hardcoded. Is there a way to infer it from the mbim device name? Thanks, Thilo
Re: FM350-GL (installed in ThinkPad P1 Gen 5)
On Tue, Sep 12, 2023 at 1:31 PM Bjørn Mork wrote: > > Turns out the challenge needs to be requested via --set-fcc-lock=0,0. > > Right. Makes sense. > > > Still, I can't get a valid unlock. > > And those challenge input values are correct? The firware isn't > expecting something other than 0,0? > I patched the Linux kernel's WWAN driver to add logging of the data sent to/from the modem and as it turns out the MBIM code path isn't even used by the official tool (although both the firmware and the unlock tool implement it). Instead AT commands are being used. Will this work for ModemManeger's firmware unlock? So far all scripts I have seen seem to rely on the MBIM device. Thanks, Thilo
Re: FM350-GL (installed in ThinkPad P1 Gen 5)
On Mon, Sep 11, 2023 at 2:45 PM Bjørn Mork wrote: > > By coincidence I spotted [2]. Could that be related? Both modems are > > manufactured by Fibocom. > > Not sure. You're not using the proxy, are you? > Not that I am aware of... > But you could also try with the proxy. Some USB devices aren't > expecting clients to come and go while the MBM session is open. > I have no idea if that's relevant to PCI, but worth testing. > > > P.S.: The challenge always being zero is also somewhat suspicious - I > > haven't been able to perform a successful unlock so far. > > Yes. Something is obviously missing here. Maybe the firmware expects > this only at a certain point in the session (like immediately after > OPEN)? Or maybe we're decoding it wrong? Did you look at th debug > dump? Or maybe the firmware wants some reqeust parameter it doesn't > get? > Turns out the challenge needs to be requested via --set-fcc-lock=0,0. Still, I can't get a valid unlock. > Is this problem the same with the official Lenovo unlock tool and > scripts? > Good question. The official beta tool does not even support my laptop model - but I can convince it to run by bind-mounting a supported laptop's string to /sys/class/dmi/id/product_family. Is there a way to capture the official tool's communication? AFAICS it is using libmbim (?) for the modem communication by calling mbim_message_intel_mutual_authentication_fcc_lock_set_new. Knowing a valid response for a given challenge would help validating the hashing algorithm. Thanks, Thilo
Re: FM350-GL (installed in ThinkPad P1 Gen 5)
Just noticed that I did not reply to the list... Next try... On Thu, Sep 7, 2023 at 10:46 AM Bjørn Mork wrote: > Nice! And I assume you have some ideas on how to compute the sha256 > hash? Blind guessing would be very hard > I hope so (keeping fingers crossed) ;-) > > Is there a way to try this procedure through mbimcli? I am currently > > running libmbim 1.28.4-1. > > I guess you need the "Intel Mutual Authentication" service for that, > which looks like it will be in libmbim 1.30 > > I.e. you need to build a current development version of libmbim to test > it for now. > I built the current dev version and applied a Linux kernel patch [1] on top of 6.5.2 that is supposed to improve handling for the FM350-GL's T7xx chipset, but I am still seeing pretty unreliable behavior communicating with the modem: $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock FCC lock status: locked Challenge: 0 $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock [10 Sep 2023, 20:23:35] -Warning ** [/dev/wwan0mbim0] error reading from the IOChannel: 'Input/output error' error: operation failed: Transaction timed out $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock FCC lock status: locked Challenge: 0 $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock FCC lock status: locked Challenge: 0 $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock FCC lock status: locked Challenge: 0 $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock FCC lock status: locked Challenge: 0 $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock FCC lock status: locked Challenge: 0 error: couldn't close device: Transaction timed out $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock FCC lock status: locked Challenge: 0 $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock FCC lock status: locked Challenge: 0 $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock error: operation failed: Transaction timed out $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock FCC lock status: locked Challenge: 0 $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock [10 Sep 2023, 20:36:39] -Warning ** [/dev/wwan0mbim0] error reading from the IOChannel: 'Input/output error' error: operation failed: Transaction timed out $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock error: operation failed: Transaction timed out error: couldn't close device: Transaction timed out $ sudo mbimcli -d /dev/wwan0mbim0 --query-fcc-lock error: operation failed: Transaction timed out dmesg error log (for some of the above errors): [ 8012.377611] mtk_t7xx :08:00.0: Port AT is not opened, drop packets [ 8012.377632] mtk_t7xx :08:00.0: Port AT is not opened, drop packets [ 8012.390960] mtk_t7xx :08:00.0: Port AT is not opened, drop packets [ 8012.409126] mtk_t7xx :08:00.0: Port AT is not opened, drop packets [ 8257.303095] mtk_t7xx :08:00.0: Port AT is not opened, drop packets [ 8257.313695] mtk_t7xx :08:00.0: Port AT is not opened, drop packets [ 8265.620529] mtk_t7xx :08:00.0: Port AT is not opened, drop packets [ 8265.622356] mtk_t7xx :08:00.0: Port AT is not opened, drop packets By coincidence I spotted [2]. Could that be related? Both modems are manufactured by Fibocom. Regards, Thilo P.S.: The challenge always being zero is also somewhat suspicious - I haven't been able to perform a successful unlock so far. [1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/patch/?id=ba2274dcfda859b8a27193e68ad37bfe4da28ddc [2] https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/184
Re: FM350-GL (installed in ThinkPad P1 Gen 5)
Hello everyone, meanwhile I have an idea how the FCC unlock for the FM350-GL works: 1. Retrieve radio state (only continue iff locked [== 0]) 2. Get challenge from modem via mbim_message_intel_mutual_authentication_fcc_lock_set_new 3. Compute a SHA256 hash 4. Unlock the modem using mbim_message_intel_mutual_authentication_fcc_lock_set_new 5. Validate radio state == 1 There is also a dev code from DMI that probably influences the hash computation. Is there a way to try this procedure through mbimcli? I am currently running libmbim 1.28.4-1. Thanks, Thilo On Mon, Oct 17, 2022 at 5:52 PM Bjørn Mork wrote: > Aleksander Morgado writes: > > > See also > https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/157 > > Nice. That will make it much easier to experiment with this. > > I found that UUID in the Windows code earlier, but Google didn't turn up > much. Only relevant hit was this: > https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/258 > > which makes sense, assuming that the L860 and FM350 use the same > methods. > > The log shows that the L860 supports CID 1 on this service, as expected: > > Service: 'unknown' > UUID: [f85d46ef-ab26-4081-9868-4d183c0a3aec]: > DSS payload: 2 > Max DSS instances: 1 > CIDs: 1 > > > None of this helps with the hard part, of course. Let's hope Lenovo > comes up with something reasonable this time. > > > Bjørn >
FM350-GL (installed in ThinkPad P1 Gen 5)
Hi there, as Lenovo couldn't fix my ThinkPad X1E4 (featuring an SDX55) I got a P1G5 as a replacement, that, however, comes with a FM350-GL as WWAN modem. I guess we need to play the FCC unlock game again (as it does not work out of the box), but first wanted to ask if anyone has any experience with this kind of modem under Linux and their FCC unlock procedure. Thanks, Thilo
Re: ModemManager 1.14.0: Can't send sms with some chars
Hi Scott, On Fri, Jul 1, 2022 at 11:20 AM Stanke, Scott wrote: > I understand the command from the Digi router shell: "modem sms-text > 16511234567 world范例" runs the following commands: > > # # mmcli -m 0 \ > # > --messaging-create-sms="text='hello world范例',number='+16511234567'" > # # mmcli -s 6 --send > > My test results, when running the above commands from the shell, shows the > "/bin/sh: can't create --messaging-create-sms=text='hello > world范例',number='+16511234567': Read-only file system" probably because I > do not have the correct permissions when running from the shell. I will ask > our Engineering team how to find if this filesystem error is seen when > executing "--messaging-create-sms..." after the router shell command: > "modem sms-text...". > AFAICS the error you get is due to an extra ">" character in the command line you quoted above (at the beginning of the second line). This causes the shell to attempt to redirect mmcli's output into a file instead of supplying the desired CLI arg. Regards, Thilo
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hello Bjørn, hi all, fascinating ;-) I made some limited progress with analysing the binary's code. There are plenty of conditions for different firmware versions (some of which I have never seen in the wild). The most recent version computes some data from the IMEI, but I don't really understand (using static analysis only) what is actually sent to the modem. Regards, Thilo Viele Grüße aus Hamburg Thilo Ginkel -- Thilo-Alexander Ginkel · Isestr. 6 · D-20144 Hamburg · Germany E-Mail/Jabber: th...@ginkel.com · @thiloginkel Phone: +49 (0)40 68895028 · Mobile/Signal: +49 (0)177 8033300 On Tue, May 10, 2022 at 11:00 AM Bjørn Mork wrote: > > More interesting stuff from that binary. The resource section contains > 3 zip-files among other stuff. Two of these contain DPR_Table.txt files > per device-id(?) and some binary blobs I don't recognise. Names might > indicate NV entries? > > > bjorn@miraculix:/tmp$ unzip -l resources/101.bin > Archive: resources/101.bin > Length DateTimeName > - -- - > 0 2020-05-04 16:27 TuneCode/ > 0 2020-05-04 16:27 TuneCode/tunecode_876D/ > 3752 2019-12-24 15:18 TuneCode/tunecode_876D/DPR_Table.txt > - --- > 3752 3 files > bjorn@miraculix:/tmp$ unzip -l resources/102.bin > Archive: resources/102.bin > Length DateTimeName > - -- - > 0 2021-03-08 17:14 TuneCode/ > 0 2021-03-08 17:15 TuneCode/tunecode_093D/ > 7462 2021-03-15 13:40 TuneCode/tunecode_093D/DPR_Table.txt > 0 2021-03-08 17:16 TuneCode/tunecode_098C/ > 7462 2021-03-15 13:40 TuneCode/tunecode_098C/DPR_Table.txt > 0 2020-05-29 19:02 TuneCode/tunecode_09C6/ > 36067 2020-04-22 16:11 TuneCode/tunecode_09C6/00029653 > 510 2020-04-30 10:40 TuneCode/tunecode_09C6/00029654 > 7403 2020-05-29 18:57 TuneCode/tunecode_09C6/DPR_Table.txt > 0 2020-10-07 14:00 TuneCode/tunecode_0A3F/ > 40314 2020-10-12 18:38 TuneCode/tunecode_0A3F/00029653 > 510 2020-10-12 18:40 TuneCode/tunecode_0A3F/00029654 > 7443 2020-10-07 13:35 TuneCode/tunecode_0A3F/DPR_Table.txt > 0 2021-02-04 10:22 TuneCode/tunecode_0A5B/ > 48254 2021-01-25 12:41 TuneCode/tunecode_0A5B/00029653 > 510 2021-01-25 12:36 TuneCode/tunecode_0A5B/00029654 > 7208 2021-02-26 15:46 TuneCode/tunecode_0A5B/DPR_Table.txt > 0 2021-03-08 14:41 TuneCode/tunecode_0A69/ > 39619 2021-03-08 14:37 TuneCode/tunecode_0A69/00029653 > 510 2021-03-08 14:37 TuneCode/tunecode_0A69/00029654 > 0 2021-03-08 14:42 TuneCode/tunecode_0A6A/ > 39619 2021-03-08 14:37 TuneCode/tunecode_0A6A/00029653 > 510 2021-03-08 14:37 TuneCode/tunecode_0A6A/00029654 > - --- >243401 23 files > > > The DPR_table files contains lines with different system+band > conbinations followed by 8 numbers which looks like they could be dB or > dBm values. Sample data: > > LTE B39 24 24 24 24 24 24 24 24 > LTE B40 24 24 24 24 24 24 23 23 > LTE B41 27 27 27 24 27 27 22.5 22.5 > LTE B42 24 24 24 24 24 22.5 24 22.5 > LTE B48 22 22 22 22 21 20.5 22 20.5 > LTE B66 24 24 24 24 24 24 18 18 > SA N1 24 24 24 24 24 24 24 24 > SA N2 24 24 24 24 24 18 24 18 > SA N3 24 24 24 24 24 24 24 24 > SA N5 24 24 24 24 24 24 19.5 19.5 > SA N7 24 24 24 24 21.5 15 24 15 > SA N8 24 24 24 24 24 24 24 24 > SA N12 24 24 24 24 24 24 19 19 > SA N20 24 24 24 24 24 24 24 24 > SA N28 24 24 24 24 24 24 24 24 > SA N38 24 24 24 24 24 14 24 14 > SA N41 27 27 27 27 21.5 15 27 15 > SA N66 24 24 24 24 24 18 24 18 > SA N77 27 27 27 27 27 18.5 27 18.5 > SA N78 27 27 27 27 27 20.5 27 20.5 > SA N79 27 27 27 27 27 16 27 16 > ENDC B5 N2 24.5 24.5 24.5 24.5 24.5 24.5 18.5 18.5 > NSA N2 B5 24 24 24 24 24 18 24 18 > ENDC B12 N2 24.5 24.5 24.5 24.5 24.5 24.5 19.5 19.5 > NSA N2 B12 24 24 24 24 24 18 24 18 > ENDC B13 N2 24.5 24.5 24.5 24.5 24.5 24.5 21.5 21.5 > NSA N2 B13 24 24 24 24 24 18 24 18 > ENDC B7 N5 24 24 24 24 21.5 14 24 14 > NSA N5 B7 24 24 24 24 24 24 18.5 18.5 > ENDC B48 N5 22 22 22 22 21 19.5 22 19.5 > NSA N5 B48 24 24 24 24 24 24 18.5 18.5 > > > The last zip contains rtsar_config_fcc and rtsar_config_row data for a > number of other(?) devices. Some of them in 2dB and 0dB variants. > Interestingly enough, this seems to be made for another Foxconn customer > and not intended for Lenovo devices at all. Doesn't look like there are > similar resources for any Lenovo modem/PC. Talk about mess. > > > bjorn@miraculix:/tmp$ unzip -l resources/106.bin > Archive: resources/10
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hello again, quick update if anyone wants to have a look before I find time to do so: The unlock is most probably in SIMService.exe, which contains the magic string "KHOIHGIUCCHHII" that is checked for in DMI and also used by the unlocking Snap... Regards, Thilo On Mon, May 9, 2022 at 8:13 PM Thilo-Alexander Ginkel wrote: > Hi Bjørn, > > thanks for your reply! I don't think that the lenovo-wwan-dpr snap > implements the OTP unlocking mechanism. > > Lenovo also just posted in their forum [1] that the new firmware > deliberately broke the unlock used by ModemManager. So that was > probably my last Lenovo laptop... > > With regards to reversing the OTP mechanism: I made some first > attempts at decompiling / diffing the Windows driver using Ghidra, but > have to admit that I am not very experienced doing so and am somewhat > lost as to which driver file actually implements the unlocking. > > Thanks, > Thilo > > [1] > https://forums.lenovo.com/t5/Other-Linux-Discussions/Finally-X55-5G-modem-works-under-linux/m-p/5082236?page=11#5639046 > > > On Sun, May 1, 2022 at 6:31 PM Bjørn Mork wrote: > > > > Bjørn Mork writes: > > > > > Wrt the implementation: Any protocol depending on closed binaries is > > > broken by design, without exception. It doesn't matter whether you use > > > a "secret" algorithm or just store keys inside the binary. Anything > that > > > was compiled can be decompiled. Sure it can be obfuscated to make that > > > harder. We all love a challenge :-) > > > > And just let me prove that fact without even modifying one byte of the > > code: > > > > root@miraculix:/tmp# cat /sys/class/dmi/id/product_family > > ThinkPad X1 Carbon 4th > > root@miraculix:/tmp# echo ThinkEdge > /tmp/product_family > > root@miraculix:/tmp# mount --bind /tmp/product_family > /sys/class/dmi/id/product_family > > root@miraculix:/tmp# cat /sys/class/dmi/id/product_family > > ThinkEdge > > > > And what do you think? There goes the machine check > > > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock > app started > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: get_product(): DT > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: MACHINE = [4] --- > THINKEDGE_SE30 = [4] > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock > app exited > > > > This doesn't work for me of course, only having the original EM7455 > > modem. But I do note that the log output changed from -1 to 4, whatever > > that means. Previously: > > > > May 1 18:21:01 miraculix DPR_Fcc_unlock_service: MACHINE = [-1] --- > THINKEDGE_SE30 = [4] > > > > Something to try out on your X1E4, maybe? > > > > > > Bjørn >
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hi Bjørn, thanks for your reply! I don't think that the lenovo-wwan-dpr snap implements the OTP unlocking mechanism. Lenovo also just posted in their forum [1] that the new firmware deliberately broke the unlock used by ModemManager. So that was probably my last Lenovo laptop... With regards to reversing the OTP mechanism: I made some first attempts at decompiling / diffing the Windows driver using Ghidra, but have to admit that I am not very experienced doing so and am somewhat lost as to which driver file actually implements the unlocking. Thanks, Thilo [1] https://forums.lenovo.com/t5/Other-Linux-Discussions/Finally-X55-5G-modem-works-under-linux/m-p/5082236?page=11#5639046 On Sun, May 1, 2022 at 6:31 PM Bjørn Mork wrote: > > Bjørn Mork writes: > > > Wrt the implementation: Any protocol depending on closed binaries is > > broken by design, without exception. It doesn't matter whether you use > > a "secret" algorithm or just store keys inside the binary. Anything that > > was compiled can be decompiled. Sure it can be obfuscated to make that > > harder. We all love a challenge :-) > > And just let me prove that fact without even modifying one byte of the > code: > > root@miraculix:/tmp# cat /sys/class/dmi/id/product_family > ThinkPad X1 Carbon 4th > root@miraculix:/tmp# echo ThinkEdge > /tmp/product_family > root@miraculix:/tmp# mount --bind /tmp/product_family > /sys/class/dmi/id/product_family > root@miraculix:/tmp# cat /sys/class/dmi/id/product_family > ThinkEdge > > And what do you think? There goes the machine check > > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app > started > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: get_product(): DT > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: MACHINE = [4] --- > THINKEDGE_SE30 = [4] > May 1 18:24:59 miraculix DPR_Fcc_unlock_service: main(): FCC unlock app > exited > > This doesn't work for me of course, only having the original EM7455 > modem. But I do note that the log output changed from -1 to 4, whatever > that means. Previously: > > May 1 18:21:01 miraculix DPR_Fcc_unlock_service: MACHINE = [-1] --- > THINKEDGE_SE30 = [4] > > Something to try out on your X1E4, maybe? > > > Bjørn
Re: Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hi, On Wed, Apr 27, 2022 at 1:50 PM Aleksander Morgado wrote: > > I can boot up Windows and downgrade the firmware, but would be > > interested in a more permanent fix. > > > > What would be needed to figure out the new unlock procedure? Any hints > > are much appreciated! > > Lenovo published already their own FCC unlock tool here > https://snapcraft.io/lenovo-wwan-dpr > Haven't tried it yet here though, I'm still using the old SDX55 firmware. > > If you don't want to use that closed source tool and If you're > interested in reverse engineering the process, looking at what that > tool does would be useful I guess. IIRC the snap does not support the modem running in an X1E4 that I own and Iam not sure wthere it implements the old or the new FCC unlock. I decompiled them some time last year and will have another look later today. A first look at the Windows drivers using Ghidra didn't reveal any FCC unlocking functionality, but frankly I am somewhat lost where to start searching (the Windows drivers are a somewhat bloated set of .sys files / DLLs). Thanks, Thilo
Lenovo T99W175 / Foxconn SDX55 update on LVFS breaks FCC unlock
Hi there, Lenovo just published a new firmware for the T99W175 / Foxconn SDX55 5G modem on LVFS [1] that effectively soft-bricks the modem under Linux as the FCC unlock no longer works. I can boot up Windows and downgrade the firmware, but would be interested in a more permanent fix. What would be needed to figure out the new unlock procedure? Any hints are much appreciated! Thanks, Thilo [1] https://fwupd.org/lvfs/devices/com.lenovo.t99w175.firmware [2] https://modemmanager.org/docs/modemmanager/fcc-unlock/#fcc-unlock-procedures-in-modemmanager--1184-1
Re: Lenovo/Foxconn Snapdragon X55 connection issues w/ newer firmware versions
On Sun, Nov 28, 2021 at 9:09 PM Aleksander Morgado wrote: > So it may really be that they've changed the unlock method already :/ > Are you able to flash back v48, or is the downgrade path not possible? > Fortunately, I can downgrade (via a Windows installation I have on a USB disk). > My firmware version in the SDX55 I have is T99W175.F0.0.0.5.8.TF.007. > > Could you run this just to confirm? > $ sudo qmicli -d /dev/wwan0mbim0 -p --dms-foxconn-set-fcc-authentication=0 > -v > That seems unsuccessful: error: couldn't run Foxconn FCC authentication: QMI protocol error (17): 'MissingArgument' Complete output attached. > Regarding the lenovo-wwan-dpr in https://snapcraft.io/lenovo-wwan-dpr, > does it help to unlock the module in the newer firmware versions? > Nope, unfortunately not, it apparently refuses to do its work: 2021-11-30T00:03:10+01:00 DPR_wwan[4779]: get_product(): WWAN DPR functionality is not supported in this product When I have a look at the decompiled DPR_wwan binary from the snap, they seem to have a product whitelist that does not include the X1E4. If the whitelist wasn't in place, they'd invoke some binary (the name of which I can't seem to figure out due to obfuscation or compiler optimization) with a --dms-set-bios-lock flag. I will leave v51 in place in case there is anything I can do to debug the situation. I may need some guidance, though. Regards, Thilo [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Opening device with flags 'proxy, auto'... [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] automatically selecting MBIM mode [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] created endpoint [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] creating MBIM device... [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] MBIM device created [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] opening MBIM device... [29 Nov 2021, 23:56:33] [Debug] opening device... [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Couldn't find descriptors file, possibly not using cdc_mbim [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Fallback to default max control message size: 4096 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message... << RAW: << length = 92 << data = 03:00:00:00:5C:00:00:00:01:00:00:00:01:00:00:00:00:00:00:00:83:8C:F7:FB:8D:0D:4D:7F:87:1E:D7:1D:BE:FB:B3:9B:01:00:00:00:01:00:00:00:2C:00:00:00:0C:00:00:00:1E:00:00:00:05:00:00:00:2F:00:64:00:65:00:76:00:2F:00:77:00:77:00:61:00:6E:00:30:00:6D:00:62:00:69:00:6D:00:30:00:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message (translated)... << Header: << length = 92 << type= command (0x0003) << transaction = 1 << Fragment header: << total = 1 << current = 0 << Contents: << service = 'proxy-control' (838cf7fb-8d0d-4d7f-871e-d71dbefbb39b) << cid = 'configuration' (0x0001) << type= 'set' (0x0001) << Fields: << DevicePath = '/dev/wwan0mbim0' << Timeout = '5' [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Received message... >> RAW: >> length = 48 >> data = 03:00:00:80:30:00:00:00:01:00:00:00:01:00:00:00:00:00:00:00:83:8C:F7:FB:8D:0D:4D:7F:87:1E:D7:1D:BE:FB:B3:9B:01:00:00:00:00:00:00:00:00:00:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Received message (translated)... >> Header: >> length = 48 >> type= command-done (0x8003) >> transaction = 1 >> Fragment header: >> total = 1 >> current = 0 >> Contents: >> status error = 'None' (0x) >> service = 'proxy-control' (838cf7fb-8d0d-4d7f-871e-d71dbefbb39b) >> cid = 'configuration' (0x0001) [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message... << RAW: << length = 16 << data = 01:00:00:00:10:00:00:00:02:00:00:00:00:10:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message (translated)... << Header: << length = 16 << type= open (0x0001) << transaction = 2 << Contents: << max control transfer = 4096 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Received message... >> RAW: >> length = 16 >> data = 01:00:00:80:10:00:00:00:02:00:00:00:00:00:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] MBIM device open [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Enabling QMI indications via MBIM... [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message... << RAW: << length = 84 << data = 03:00:00:00:54:00:00:00:03:00:00:00:01:00:00:00:00:00:00:00:A2:89:CC:33:BC:BB:8B:4F:B6:B0:13:3E:C2:AA:E6:DF:13:00:00:00:01:00:00:00:24:00:00:00:01:00:00:00:0C:00:00:00:18:00:00:00:D1:A3:0B:C2:F9:7A:6E:43:BF:65:C7:E2:4F:B0:F0:D3:01:00:00:00:01:00:00:00 [29 Nov 2021, 23:56:33] [Debug] [/dev/wwan0mbim0] Sent message (translated)... << Header: << length = 84 <<
Re: Lenovo/Foxconn Snapdragon X55 connection issues w/ newer firmware versions
Hi Aleksander, On Sun, Nov 28, 2021 at 6:50 PM Aleksander Morgado wrote: > Since MM 1.18.4 the FCC unlock operation needs to be explicitly > configured by the user, did you do that already, or is this issue > happening even after doing that? > > https://modemmanager.org/docs/modemmanager/fcc-unlock/#fcc-unlock-procedures-in-modemmanager--1184-1 > I configured the FCC unlock in MM as per the instructions you mentioned: $ ll /etc/ModemManager/fcc-unlock.d total 4,0K lrwxrwxrwx 1 root root 56 Nov 28 11:05 105b:e0ab -> /usr/share/ModemManager/fcc-unlock.available.d/105b:e0ab v48 will start working afterwards, v51 won't (logs I provided are w/ FCC unlock configured). Thanks, Thilo
Lenovo/Foxconn Snapdragon X55 connection issues w/ newer firmware versions
Hi there, I just got a new Lenovo X1 Extreme Gen 4 that comes with a Snapdragon X55 WWAN modem by Foxconn. I'm running Arch Linux w/ kernel 5.15.5, ModemManager 1.18.4, libmbim 1.26.2 and libqmi 1.30.2. The X55 seems to be supported for older firmware versions (<= v48?) after setting up the FCC unlock. Currently published versions v50 and v51 cause the connection to fail, though: -- 8< -- Nov 28 11:23:50 vega systemd[1]: Starting Modem Manager... Nov 28 11:23:50 vega ModemManager[1135]: ModemManager (version 1.18.4-1) starting in system bus... Nov 28 11:23:50 vega ModemManager[1135]: [qrtr] socket lookup from 1:0 Nov 28 11:23:50 vega ModemManager[1135]: [qrtr] initial lookup finished Nov 28 11:23:50 vega systemd[1]: Started Modem Manager. Nov 28 11:23:51 vega ModemManager[1135]: opening device... Nov 28 11:23:51 vega ModemManager[1135]: cannot connect to proxy: Could not connect: Connection refused Nov 28 11:23:51 vega ModemManager[1135]: spawning new mbim-proxy (try 1)... Nov 28 11:23:51 vega ModemManager[1135]: [/dev/wwan0mbim0] Couldn't find descriptors file, possibly not using cdc_mbim Nov 28 11:23:51 vega ModemManager[1135]: [/dev/wwan0mbim0] Fallback to default max control message size: 4096 Nov 28 11:23:52 vega ModemManager[1135]: [wwan0mbim0/mbim] MBIM device is not QMI capable Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] channel destroyed Nov 28 11:23:52 vega ModemManager[1135]: [device /sys/devices/pci:00/:00:1c.4/:08:00.0] creating modem with plugin 'foxconn' and '4' ports Nov 28 11:23:52 vega ModemManager[1135]: [base-manager] modem for device '/sys/devices/pci:00/:00:1c.4/:08:00.0' successfully created Nov 28 11:23:52 vega ModemManager[1135]: [base-manager] couldn't check support for device '/sys/devices/pci:00/:00:1c.6/:09:00.0': not supported by any plugin Nov 28 11:23:52 vega ModemManager[1135]: opening device... Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] Couldn't find descriptors file, possibly not using cdc_mbim Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] Fallback to default max control message size: 4096 Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] Opening device with flags 'version-info, proxy, mbim, expect-indications'... Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] created endpoint Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] creating MBIM device... Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] MBIM device created Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] opening MBIM device... Nov 28 11:23:52 vega ModemManager[1135]: opening device... Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] Couldn't find descriptors file, possibly not using cdc_mbim Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] Fallback to default max control message size: 4096 Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] MBIM device open Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] Checking version info (15 retries)... Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0] QMI Device supports 36 services: Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]ctl (1.5) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]wds (1.193) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]dms (1.79) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]nas (1.25) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]qos (1.18) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]wms (1.10) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]auth (1.14) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]at (1.6) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]voice (2.1) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]cat2 (2.24) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]uim (1.77) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]pbm (1.4) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]test (1.0) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]loc (2.131) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]sar (1.0) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]ims (1.91) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]ts (1.0) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]tmd (1.0) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]wda (1.24) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]csvt (1.6) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]imsa (1.44) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]coex (1.0) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]pdc (1.0) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]rfrpe (1.0) Nov 28 11:23:52 vega ModemManager[1135]: [/dev/wwan0mbim0]dsd (1.67) Nov 28
