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
