Thomas Schäfer <tschae...@t-online.de> writes: > [ 369.482170] option 1-2:1.0: GSM modem (1-port) converter detected > [ 369.482562] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0 > [ 369.482639] option 1-2:1.1: GSM modem (1-port) converter detected > [ 369.483008] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1 > [ 369.483082] option 1-2:1.2: GSM modem (1-port) converter detected > [ 369.486206] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB2 > [ 369.507370] option 1-2:1.3: GSM modem (1-port) converter detected > [ 369.507707] option 1-2:1.4: GSM modem (1-port) converter detected > [ 369.508139] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB4
Were 4 serial devices expected? What does the device config look like (lsusb -v ...)? Maybe the option driver is configured to bind to any interface on this modem, "stealing" the QMI interface before qmi_wwan gets the chance? Difficult to know based on the available info.... You could try to manually unload the drivers and then reload them in the opposite order to see what happens. rmmod option rmmod qmi_wwan modprobe qmi_wwan modprobe option If the distro (or some relates script) use the dynamic ID feature, then cat /sys/bus/usb-serial/drivers/option1/new_id would be enlightening. You could also try to manually verify a match against the putput of modinfo -F alias option modinfo -F alias qmi_wwan but that will be challenging due to the mix of vendor id and class matching (Huawei devices use subclass + protocol matches). Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list