Graham Inggs <graham.in...@uct.ac.za> writes: >> Try QMI. Get libqmi with qmicli and temporarily bind the qmi_wwan driver >> to the ethernet function instead of cdc_ether. The 2-5:1.1 below could >> have changed since the logs you posted. Check it and adjust as >> necessary (this recipe will work for Windows mode as well, except that >> the already bound driver most likely is option): >> >> modprobe qmi_wwan >> echo 2-5:1.1 >/sys/bus/usb/drivers/cdc_ether/unbind >> echo 2-5:1.1 >/sys/bus/usb/drivers/qmi_wwan/bind > This command failed with: > bash: echo: write error: No such device > > However this did something: > echo 12d1 14ac >/sys/bus/usb/drivers/cdc_wdm/new_id
Doh! Don't know how I could forget that. But you figured it out anyway. Thanks. > Then: >> qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer > [/dev/cdc-wdm0] Device manufacturer retrieved: > Manufacturer: 'QUALCOMM INCORPORATED' Great! I think we should add this device ID to qmi_wwan then, which also is likely to fix the mac address problem. Anyone against using interface number matching instead of class/subclass/protocol to make the same rule apply to both device modes? In the spirit of symmetry this implies that we will use interface number matching for the cdc_ether blacklist as well. Or is that more confusing? I'm thinking of something like this in qmi_wwan: {QMI_FIXED_INTF(0x12d1, 0x14ac, 1)}, /* Huawei E1820 */ with matching blacklists in cdc_ether: { USB_DEVICE_INTERFACE_NUMBER(0x12d1, 0x14ac, 1), .driver_info = 0, }, and option: { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0x14ac, 0xff, 0xff, 0xff), .driver_info = (kernel_ulong_t) &net_intf1_blacklist }, I believe that should do whether the device is in "Linux mode" or "Windows mode" >> That is unexpected given that Windows use a different address. Maybe >> the device already was "locked" to the 0/1/2/3/4/5 address when you >> tried the other one? > > I think I tried the other addresses before I tried 0/1/2/3/4/5, but > will check again. Thanks. If it's only this address working, then the current workaround in qmi_wwan isn't enough. Do you have a recent version of the qmi_wwan driver? It's easy to find out with your device: If the wwan0 address is a random one, then the driver has applied the workaround. It would be interesting to know if this works. You can connect the same way you do with cdc_ether if you want to test it. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list