Hmm, this suggestion should probably go to distribution maintainers.

What do you think? Should I add this modconf file to the usb_modeswitch distribution and explain the issue in the Changelog?

Note that you have to run usb_modeswitch as "root" or with "sudo" when using it manually.

I have posted the report that triggered the change with "change" (haha).

https://bugzilla.kernel.org/show_bug.cgi?id=209469#c16

I'll have to check how a switch back to "add" only will affect reboot behaviour.

Thanks for that information !!

The easiest way is to copy an existing config file like "12d1:1583", put it in "/etc/usb_modeswitch.d" and change the name to "12d1:1591". That should make the modem switch the next time you insert it. To check if it worked, either run the "dmesg" command line...

This problem may also be power-supply-related. If the USB power is not reliable, a modem may reset itself just when it draws more power while starting transmission (connecting to the cell network). It is known to have happened on older Raspberry Pis and on mobile devices (e.g. Android phones via the...

Is there a way to detect these new modems/firmwares, apart from the USB ID?

That's great information, thanks!!!

You can only try to send AT commands to one of the other ttyUSB ports. Sometimes they provide a DIAG port where you can do all of what you listed.

From Linux, try the "minicom" application - example:
minicom -D /dev/ttyUsb1

Yes, you could say that. When wireless USB modems emerged, there wasn't much choice regarding drivers. So they mostly chose the USB simulation of a serial port, like it was used on analogue landline modems. The drivers and the overlaying tools (pppd) were widely available. However, that serial proto...

Newer versions of udev will kill subprocesses started by rules if they are running 'too long'. I suspect this is happening in your case. Standard usb_modeswitch installations are working around this by using a systemd service file. This allows the detachment of the mode-switching process from udev s...

I have responded to the kernel bugzilla report. I'll see if I can pinpoint the reason why I introduced the "change" event in the udev rule.

Are you using a proper terminal program to issue AT commands?

I'm using "minicom" for this purpose.

Hmm, the network interface seems to be set up nicely during boot. Not sure what the problem is. It's correctly detected as a NCM device with Huawei-specific flavour, and a network interface is created (see last line in excerpt). [ 5.671792] huawei_cdc_ncm 3-2:1.1: MAC-Address: 0c:5b:8f:27:9a:64 [ 5....

It's possible that there is a NCM port exposed in that mode.

Can you post the output of "lsusb -v -d 12d1:1c05" here?

Be sure to paste the output between [code] tags to keep the formatting. The button in the editor shows '</>'.