Re: [MM] Huawei E1820 and NDISDUP

[Bjørn Mork <bjorn mork no>]

Graham Inggs <graham inggs 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