Huwaei 4G mobile broadband module is not recognizing SIM card

[bennypr0fane]

Hello, I just put a new LTE/4G modem (M2 card) into my laptop, it’s this model:

Bus 001 Device 002: ID 12d1:15bb Huawei Technologies Co., Ltd. ME936 LTE/HSDPA+ 4G modem

I could have ordered the laptop with this exact model already built in back then, now I found it much cheaper and installed it.

garuda-inxi
System:
Kernel: 6.6.5-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 13.2.1
clocksource: tsc available: acpi_pm
parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
root=UUID=dc229e5a-50c1-478a-b84b-e60401e4d6c0 rw rootflags=subvol=@
quiet quiet rd.udev.log_priority=3 vt.global_cursor_default=0
resume=UUID=258393c9-45c2-4f11-9c89-8fb56cf7d7ab loglevel=3 ibt=off
Desktop: KDE Plasma v: 5.27.10 tk: Qt v: 5.15.11 wm: kwin_wayland vt: 1
dm: SDDM Distro: Garuda Linux base: Arch Linux
Machine:
Type: Laptop System: TUXEDO product: TUXEDO v: N/A
serial: <superuser required> Chassis: Notebook type: 10
serial: <superuser required>
Mobo: TUXEDO model: N141CU serial: <superuser required> UEFI: INSYDE
v: 1.07.07RTR1 date: 11/08/2019
Battery:
ID-1: BAT0 charge: 35.1 Wh (94.6%) condition: 37.1/35.3 Wh (105.0%)
volts: 11.9 min: 11.4 model: Notebook BAT type: Li-ion serial: <filter>
status: discharging
Device-1: hidpp_battery_0 model: Logitech Wireless Mouse M315/M235
serial: <filter> charge: 100% (should be ignored) rechargeable: yes
status: discharging
CPU:
Info: model: Intel Core i7-10510U bits: 64 type: MT MCP
arch: Comet/Whiskey Lake note: check gen: core 10 level: v3 note: check
built: 2018 process: Intel 14nm family: 6 model-id: 0x8E (142)
stepping: 0xC (12) microcode: 0xF8
Topology: cpus: 1x cores: 4 tpc: 2 threads: 8 smt: enabled cache:
L1: 256 KiB desc: d-4x32 KiB; i-4x32 KiB L2: 1024 KiB desc: 4x256 KiB
L3: 8 MiB desc: 1x8 MiB
Speed (MHz): avg: 450 high: 800 min/max: 400/4900 scaling:
driver: intel_pstate governor: powersave cores: 1: 400 2: 400 3: 400 4: 400
5: 400 6: 400 7: 400 8: 800 bogomips: 36799
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Vulnerabilities: <filter>
Graphics:
Device-1: Intel CometLake-U GT2 [UHD Graphics] vendor: CLEVO/KAPOK
driver: i915 v: kernel arch: Gen-9.5 process: Intel 14nm built: 2016-20
ports: active: eDP-1 empty: DP-1,HDMI-A-1,HDMI-A-2 bus-ID: 00:02.0
chip-ID: 8086:9b41 class-ID: 0300
Device-2: Chicony USB2.0 Camera driver: uvcvideo type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 mode: 2.0 bus-ID: 1-7:4 chip-ID: 04f2:b649
class-ID: 0e02
Display: wayland server: X.org v: 1.21.1.9 with: Xwayland v: 23.2.2
compositor: kwin_wayland driver: X: loaded: modesetting
alternate: fbdev,intel,vesa dri: iris gpu: i915 display-ID: 0
Monitor-1: eDP-1 res: 1920x1080 size: N/A modes: N/A
API: EGL v: 1.5 hw: drv: intel iris platforms: device: 0 drv: iris
device: 1 drv: swrast surfaceless: drv: iris wayland: drv: iris x11:
drv: iris inactive: gbm
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 23.2.1-arch1.2
glx-v: 1.4 direct-render: yes renderer: Mesa Intel UHD Graphics (CML GT2)
device-ID: 8086:9b41 memory: 14.96 GiB unified: yes display-ID: :1.0
API: Vulkan v: 1.3.269 layers: 3 device: 0 type: integrated-gpu name: Intel
UHD Graphics (CML GT2) driver: mesa intel v: 23.2.1-arch1.2
device-ID: 8086:9b41 surfaces: xcb,xlib,wayland device: 1 type: cpu
name: llvmpipe (LLVM 16.0.6 256 bits) driver: mesa llvmpipe
v: 23.2.1-arch1.2 (LLVM 16.0.6) device-ID: 10005:0000
surfaces: xcb,xlib,wayland
Audio:
Device-1: Intel Comet Lake PCH-LP cAVS vendor: CLEVO/KAPOK
driver: snd_hda_intel v: kernel alternate: snd_soc_skl,snd_sof_pci_intel_cnl
bus-ID: 00:1f.3 chip-ID: 8086:02c8 class-ID: 0403
API: ALSA v: k6.6.5-zen1-1-zen status: kernel-api with: aoss
type: oss-emulator tools: N/A
Server-1: PipeWire v: 1.0.0 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: CLEVO/KAPOK driver: r8169 v: kernel pcie: gen: 1 speed: 2.5 GT/s
lanes: 1 port: 5000 bus-ID: 3b:00.1 chip-ID: 10ec:8168 class-ID: 0200
IF: enp59s0f1 state: down mac: <filter>
Device-2: Intel Wireless-AC 9260 driver: iwlwifi v: kernel pcie: gen: 2
speed: 5 GT/s lanes: 1 bus-ID: 40:00.0 chip-ID: 8086:2526 class-ID: 0280
IF: wlp64s0 state: up mac: <filter>
IF-ID-1: wwp0s20f0u2c2 state: down mac: <filter>
Bluetooth:
Device-1: Intel Wireless-AC 9260 Bluetooth Adapter driver: btusb v: 0.8
type: USB rev: 2.0 speed: 12 Mb/s lanes: 1 mode: 1.1 bus-ID: 1-10:5
chip-ID: 8087:0025 class-ID: e001
Report: btmgmt ID: hci0 rfk-id: 0 state: down bt-service: enabled,running
rfk-block: hardware: no software: yes address: <filter> bt-v: 5.1 lmp-v: 10
status: discoverable: no pairing: no
Drives:
Local Storage: total: 953.87 GiB used: 127.41 GiB (13.4%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Intel model: SSDPEKNW010T8
size: 953.87 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
lanes: 4 tech: SSD serial: <filter> fw-rev: 002C temp: 27.9 C scheme: GPT
Partition:
ID-1: / raw-size: 936.72 GiB size: 936.72 GiB (100.00%)
used: 127.41 GiB (13.6%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
used: 576 KiB (0.2%) fs: vfat dev: /dev/nvme0n1p1 maj-min: 259:1
ID-3: /home raw-size: 936.72 GiB size: 936.72 GiB (100.00%)
used: 127.41 GiB (13.6%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
ID-4: /var/log raw-size: 936.72 GiB size: 936.72 GiB (100.00%)
used: 127.41 GiB (13.6%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
ID-5: /var/tmp raw-size: 936.72 GiB size: 936.72 GiB (100.00%)
used: 127.41 GiB (13.6%) fs: btrfs dev: /dev/nvme0n1p2 maj-min: 259:2
Swap:
Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
ID-1: swap-1 type: zram size: 15.32 GiB used: 0 KiB (0.0%) priority: 100
comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 8 dev: /dev/zram0
ID-2: swap-2 type: partition size: 16.85 GiB used: 0 KiB (0.0%)
priority: -2 dev: /dev/nvme0n1p3 maj-min: 259:3
Sensors:
System Temperatures: cpu: 44.0 C pch: 42.0 C mobo: N/A
Fan Speeds (rpm): N/A
Info:
Processes: 259 Uptime: 9m wakeups: 0 Memory: total: 16 GiB note: est.
available: 15.32 GiB used: 4.85 GiB (31.7%) Init: systemd v: 255
default: graphical tool: systemctl Compilers: gcc: 13.2.1 Packages: 1716
pm: pacman pkgs: 1710 libs: 512 tools: pamac,paru pm: flatpak pkgs: 6
Shell: fish v: 3.6.2 default: Bash v: 5.2.21 running-in: konsole
inxi: 3.3.31
Garuda (2.6.19-2):
System install date:     2023-10-28
Last full system update: 2023-12-10
Is partially upgraded:   No
Relevant software:       snapper NetworkManager dracut
Windows dual boot:       No/Undetected
Failed units:            nmb.service

It appears that the SIM card is not being recongnized:

● ModemManager.service - Modem Manager
Loaded: loaded (/usr/lib/systemd/system/ModemManager.service; enabled; preset: disabled)
Active: active (running) since Sun 2023-12-10 21:41:47 CET; 57min ago
Main PID: 714 (ModemManager)
Tasks: 4 (limit: 18764)
Memory: 12.0M (peak: 13.1M)
CPU: 131ms
CGroup: /system.slice/ModemManager.service
└─714 /usr/bin/ModemManager

Dez 10 21:41:47 paul-grd systemd[1]: Started Modem Manager.
Dez 10 21:41:51 paul-grd ModemManager[714]: <msg> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1d.0/0000:3b:00.1': not supported by any plugin
Dez 10 21:41:51 paul-grd ModemManager[714]: <msg> [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:1d.1/0000:40:00.0': not supported by any plugin
Dez 10 21:42:22 paul-grd ModemManager[714]: <msg> [device /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2] creating modem with plugin 'huawei' and '5' ports
Dez 10 21:42:22 paul-grd ModemManager[714]: <wrn> [plugin/huawei] could not grab port ttyUSB1: Cannot add port 'tty/ttyUSB1', unhandled port type
Dez 10 21:42:23 paul-grd ModemManager[714]: <msg> [base-manager] modem for device '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2' successfully created
Dez 10 21:42:23 paul-grd ModemManager[714]: <msg> [modem0] state changed (unknown -> locked)
Dez 10 21:42:23 paul-grd ModemManager[714]: <wrn> [modem0] modem couldn't be initialized: Couldn't check unlock status: SIM not inserted
Dez 10 21:42:23 paul-grd ModemManager[714]: <msg> [modem0] state changed (locked -> failed)
Dez 10 21:42:23 paul-grd ModemManager[714]: <wrn> [modem0] error initializing: Modem in failed state: sim-missing

~ mmcli -m 0
-----------------------------
General  |              path: /org/freedesktop/ModemManager1/Modem/0
|         device id: 84851348140b7877e93f1e9d5ba49081f0399471
-----------------------------
Hardware |      manufacturer: Huawei Technologies Co., Ltd.
|             model: ME936
| firmware revision: 11.350.20.01.00
|         supported: gsm-umts, lte
|           current: gsm-umts, lte
|      equipment id: 862595020755910
-----------------------------
System   |            device: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2
|           physdev: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-2
|           drivers: option, cdc_ncm
|            plugin: huawei
|      primary port: ttyUSB0
|             ports: ttyUSB0 (at), ttyUSB2 (at), ttyUSB3 (at),
|                    wwp0s20f0u2c2 (net)
-----------------------------
Status   |             state: failed
|     failed reason: sim-missing
|       power state: on
-----------------------------
Modes    |         supported: allowed: any; preferred: none
|           current: allowed: any; preferred: none
-----------------------------
IP       |         supported: ipv4, ipv6, ipv4v6
-----------------------------
3GPP     |              imei: 862595020755910

I tried the sim card in an Android phone and made sure it doesn’t ask for the PIN, and it’s working fine. What could be the reason it’s not recognized?
I found a AUR package with udev rules, but can’t install it - its Git repo is 404.
Are the udev rules what I’m missing? If so, can anyone help me find the proper ones? And how do I put them in place…

This article by the OEM (English version not found sorry) explains what to do, but for Tuxedo OS, and it assumes the presence of their home-grown driver management tool, which isn’t available for Arch.

Btw, when I configure the ISP connection in KDE System Settings > Connections, the modem isn’t offered up specifically, instead if only offers “Generic GSM device” or “Generic CDMA device”, although lsusb and mmcli say it’s there - so that’s odd, too.

[meanruse]

These links may have something relevant
No mobile broadband internet connection - #5 by SearingSunrazeSmash - Cinnamon - EndeavourOS
LiveUSB Mobile broadband - #8 by anon3337769 - Newbie - EndeavourOS

How is an LTE connection established under TUXEDO OS? - TUXEDO Computers

“Tomte” is all perl and shell, I’m not sure it will do the right thing on Arch though (it may assume file locations that are different here). Maybe the udev rules can be manually copied from there.

Around here: tuxedo-tomte/src/tuxedo-tomte at ea34e0982e0cc10304539277c141a0f4ff05c689 · tuxedocomputers/tuxedo-tomte · GitHub

	my $fileName1 = '/etc/modprobe.d/huawei-me906s.conf';
	my $fileName2 = '/etc/udev/rules.d/77-mm-huawei-configuration.rules';
	my $niceTime = getBackupFileTime();
	my $fileText1 = "# added by tuxedo-tomte, any changes might be overwritten by Tomte as needed!! ".$niceTime."\n".
		"options usbserial vendor=0x12d1 product=0x15c1\n";
	my $fileText2 = "# added by tuxedo-tomte, any changes might be overwritten by Tomte as needed!! ".$niceTime."\n".
		"ACTION==\"add|change\", SUBSYSTEM==\"usb\", ENV{DEVTYPE}==\"usb_device\", ATTR{idVendor}==\"12d1\", ATTR{idProduct}==\"15c1\", ATTR{bNumConfigurations}==\"3\", ATTR{bConfigurationValue}!=\"2\", ATTR{bConfigurationValue}=\"2\"";

Huawei ME936 modulo LTE Debian 10 - Edmond's Weblog

old one, I guess it still applies though:
Huawei ME936 Modem does not connect [solved] / Kernel & Hardware / Arch Linux Forums

[tbg]

You could try whitelisting your modem.

see:

https://www.freedesktop.org/software/ModemManager/api/latest/ref-overview-modem-filter.html

Create:

/lib/udev/rules.d/78-mm-allowlist-internal-modem.rules

With the the following contents:

ACTION!="add|change|move", GOTO="mm_allowlist_internal_modem_end"
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15bb", ENV{ID_MM_DEVICE_PROCESS}="1"
LABEL="mm_allowlist_internal_modem_end"

Save the newly created rule, then reboot.

[bennypr0fane]

@tbg

You could try whitelisting your modem.

This hasn’t worked. Could there be some problem with the driver? I haven’t installed one explicitly, and found nothing in the repos either.

@meanruse

old one, I guess it still applies though:
Huawei ME936 Modem does not connect [solved] / Kernel & Hardware / Arch Linux Forums

I applied these settings, but still no luck although they are almost matching what this Italian one says.

[tbg]

@bennypr0fane

Could there be some problem with the driver? I haven’t installed one explicitly

If you haven’t installed anything yet, then this is likely what you are missing:

https://aur.archlinux.org/packages/huawei-me936-udev

[meanruse]

The problem is, that repo is no more. https://github.com/StevenSeifried/udev-rules/

@bennypr0fane

I found a AUR package with udev rules , but can’t install it - its Git repo is 404.

I tried searching around, hoping to find a fork, but I had no luck.
I guess it was supposed to be very similar to the the udev rules we suggested already.

Maybe not all ME936 are made equal?
This one is 12d1:15bb, the udev rules in Tuxedo’s Tomte say 12d1:15c1, and the rest of the rule is not exactly the same.

I checked linux-hardware Huawei Technologies ME936 LTE/HSDPA+ 4G modem but I only found generic messages there: “device is known to have problem” and “Driver is not found or not configured. The device is supported by kernel versions 4.15 and newer. You are probably need to configure system for the device to work properly (modify kernel config, install firmware, etc.).”

I hoped to find a driver or something on Huawei website, but no dice Search and no way WLAN Software & Firmware Download - Huawei as if they never made this product.

I feel there’s still hope with udev though, I just know too little to advise anything besides to compare them and try all the options.

[tbg]

Did you try this already?

Create:

etc/udev/rules.d/77-mm-huawei-configuration.rules 

ACTION=="add|change", SUBSYSTEM=="usb", \
ENV{DEVTYPE}=="usb_device", \
ATTR{idVendor}=="12d1", ATTR{idProduct}=="15bb", \
ATTR{bNumConfigurations}=="3", ATTR{bConfigurationValue}!="3" \
ATTR{bConfigurationValue}="3"

Be sure the syntax is identical if you think you’ve tested this before!

Don’t forget to reboot.

---

Edit:

I don’t think the udev rule’s name matters too much, but you might want to rename it to 77-mm-huawei-net-port-types.rules. That name I saw recommended for Arch. The prefix number is usually more important as it sets the precedence level for which rules are executed first.

---

Edit yet again:

Below may be the missing pieces to the puzzle.

Create:

/etc/modules-load.d/huawai-me936.conf

With the contents below:

qcserial
usbserial

Create:

/etc/modprobe.d/huawai-me936.conf 

With the contents below:

options usbserial vendor=0x12d1 product=0x15bb

And, of course be sure to reboot.

I believe the above conf files along with the udev rule were the files originally contained in the AUR package AUR (en) - huawei-me936-udev .

[bennypr0fane]

@tbg

Did you try this already?

Yes, I already tried these configs (including your additional edits). They are all in the Arch forums link provided by @meanruse, I think identically - except possibly for this filename: huawai-me936.conf, which imo should probably be spelled huaw**e**i, but I have no idea if it really makes a difference (probably it just needs to be cogruent with other places where it’s referenced?).
I also renamed the udev rules file to 77-mm-huawei-net-port-types.rules - all to no avail.
THEN I thought I should check whether I properly installed the hardware inside the laptop, and found out I had forgotten all about the antennas! I had noticed those two loose cables before, but now I also saw the tiny pins on the LTE module they should go on, labeled “Main” and “Aux/GPS”. I have no idea which antenna should go on which pin, so I’ve tried both options - but still no luck!
Would anyone happen to no any details about the antennas? One has a black sleeve and the other a blue one. Both have some alphanumeric code on them that tells me nothing.

@meanruse

Maybe not all ME936 are made equal?
This one is 12d1:15bb, the udev rules in Tuxedo’s Tomte say 12d1:15c1, and the rest of the rule is not exactly the same.

The udev rules used by Tuxedo have two sets of rules for two models: ME936 and ME906s. The ME936 advertises itself as being

Bus 001 Device 002: ID 12d1:15bb Huawei Technologies Co., Ltd. ME936 LTE/HSDPA+ 4G modem

so these are the correct ones I think (vendor 12d1, product 15bb).

[meanruse]

oops, I linked to the wrong ones… good catch!

As for the typo in the filename, as far as I know it should not matter (to the OS) that it matches anything, only the number for sorting. Another good catch though.

Speaking of hardware, I know it sounds silly but are you 100% sure the card is making good contact, they made so many different sizes and holders. And does it make a difference if powering on with the card inserted vs hot swapping the card?

I also found something rather obscure about SIM detection on the ME936 M.2, I’m still reading it and I’m not yet sure it is relevant though. edit: Seems not so far.

[tbg]

@bennypr0fane

Yes, I already tried these configs (including your additional edits). They are all in the Arch forums link provided by @meanruse,

No offense, but how are we to know exactly what you have tried, as you have posted zero terminal outputs for methods you have tested.

@bennypr0fane

@tbg

You could try whitelisting your modem.

This hasn’t worked.

Again, insufficient information.

@tbg

Did you try this already?

Create:

etc/udev/rules.d/77-mm-huawei-configuration.rules 

ACTION=="add|change", SUBSYSTEM=="usb", \
ENV{DEVTYPE}=="usb_device", \
ATTR{idVendor}=="12d1", ATTR{idProduct}=="15bb", \
ATTR{bNumConfigurations}=="3", ATTR{bConfigurationValue}!="3" \
ATTR{bConfigurationValue}="3"

Be sure the syntax is identical if you think you’ve tested this before!

Use the cat command with the filename to display contents of any new rule you have created, as so:

# cat /etc/udev/rules.d/77-mm-huawei-configuration.rules 
ACTION=="add|change", SUBSYSTEM=="usb", \
ENV{DEVTYPE}=="usb_device", \
ATTR{idVendor}=="12d1", ATTR{idProduct}=="15bb", \
ATTR{bNumConfigurations}=="3", ATTR{bConfigurationValue}!="3" \
ATTR{bConfigurationValue}="3"

This way we know the rule has been named correctly, that it is in the proper location, and what exactly the contents of the rule are. Any less simply leaves helpers blundering around in the dark.

Please provide proper terminal outputs for any fixes you have attempted.

[bennypr0fane]

@tbg

No offense, but how are we to know exactly what you have tried, as you have posted zero terminal outputs for methods you have tested.

Sorry about that, I thought referencing the Arch forum thread was sufficiently precise, as I did exactly what was posted there, plus your suggestions - but let’s see some proof:

~ lsusb | grep Huawei
Bus 001 Device 002: ID 12d1:15bb Huawei Technologies Co., Ltd. ME936 LTE/HSDPA+ 4G modem

~ cat /etc/modules-load.d/huawei-me936.conf
File: /etc/modules-load.d/huawei-me936.conf
qcserial
usbserial

~ cat /etc/modprobe.d/huawei-me936.conf
File: /etc/modprobe.d/huawei-me936.conf
options usbserial vendor=0x12d1 product=0x15bb

~ cat /etc/udev/rules.d/77-mm-huawei-net-port-types.rules
File: /etc/udev/rules.d/77-mm-huawei-net-port-types.rules
ACTION=="add|change", SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="12d1",
ATTR{idProduct}=="15bb", ATTR{bNumConfigurations}=="3", ATTR{bConfigurationValue}!="3" ATTR{
bConfigurationValue}="3"

~ cat /lib/udev/rules.d/78-mm-allowlist-internal-modem.rules
File: /lib/udev/rules.d/78-mm-allowlist-internal-modem.rules
ACTION!="add|change|move", GOTO="mm_allowlist_internal_modem_end"
ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="15bb", ENV{ID_MM_DEVICE_PROCESS}="1"
LABEL="mm_allowlist_internal_modem_end"

It caught my eye only now that some values are with == and some are with just one =, (because I use Kate for editing, and it displays the double ==as just one long one, and != as a longer, crossed-out =). Gotta say I can’t make out a sensible pattern here.
However, those double == are also present in the arch forum thread and in @tbg 's instruction for the whitelist, but I thought I’d give it a try with using only single = and reboot - no luck though. I guess I should return it to the versions posted here?

I’m still not 100% sure if I have the modem installed properly now, because of the antennas (I did try both ways) - but suppose I got it wrong - would that be a reason for the modem not recognizing SIM cards? The actual problem is still this:

~ mmcli -m 0
Status   |             state: failed
         |     failed reason: sim-missing
         |       power state: on

~ systemctl status ModemManager.service | grep wrn
Dez 14 21:51:26 paul-grd ModemManager[721]: <wrn> [plugin/huawei] could not grab port ttyUSB1: Cannot add port 'tty/ttyUSB1', unhandled port type
Dez 14 21:51:27 paul-grd ModemManager[721]: <wrn> [modem0] modem couldn't be initialized: Couldn't check unlock status: SIM not inserted
Dez 14 21:51:27 paul-grd ModemManager[721]: <wrn> [modem0] error initializing: Modem in failed state: sim-missing

What could be the reason for the warnings? What does the “unhandled port type” mean?

[bennypr0fane]

@meanruse

Speaking of hardware, I know it sounds silly but are you 100% sure the card is making good contact, they made so many different sizes and holders. And does it make a difference if powering on with the card inserted vs hot swapping the card?

Can’t be 100% sure while the card holder is in the chassis. I did take out the PCB that hosts the card holder (along with one usb port and the power button) and tested the sim insertion mechanism a couple times - while powered off - and it seems very solid. Wondering if I should try booting up with all the innards hanging out…

It would be interesting though if I could track what happens in the logs when SIM is inserted. Would anyone know the right command /place to look for that?

[bennypr0fane]

I recently found solutions to a longer topic I started, but it’s already closed. I’d like to post the solution, I think it might be reasonably valuable.
Is this the right place to request a re-opening? If not, where/who to ask?

[NaN]

Hey @bennypr0fane I have opened the topic again please post your solution.

[bennypr0fane]

So, with much assistance from the kind support of the OEM, I now have a working LTE module!

1. I inserted the SIM wrong! This article, previously not available on Tuxedo’s website (I think they put it back up now) shows it: Not only does go in contacts facing down, but also with the slanted side last, i.e. the end that has a corner cut off faces out. Seriously, that option never crossed my mind.
   So this fixed the problem of the SIM not being recognized.

I managed to get a connection now, but an extremly unstable one under Garuda, it was cut off (deactivated) every few seconds. Following the advice from support, I installed Tuxedo OS on a separate SSD, and voila, the connection worked perfectly! I had previously tried Tuxedo OS from a live medium, but turns out Tomte doesn’t work there.

2. Tuxedo support also sent me this legacy article, featuring the udev rules used in Tuxedo OS (not identical to the current article linked above). In Garuda, I did not have qcserial in the /etc/modprobe.d/huawei-me936.conf file, so I added that, and copied over the contents of /etc/udev/rules.d/77-mm-huawei-configuration.rules again to be sure.

So, it works now! Mostly stable connection, very speedy 4G!

Thanks to everyone for the involved help!