Re: [MM] Huawei E1820 and NDISDUP

[Bjørn Mork <bjorn mork no>]

Graham Inggs <graham inggs uct ac za> writes:

> So many questions! :)  I'm going to try and answer them in one post.
>
> > Quick question, in Windows does the device have the 00/1/2/3/4/5 hardware address?
>
> No, in Windows the MAC address was 00:1E:10:1F:E9:48
>
> > Can we get lsusb -v output for the device too though?
>
> I attach three lsusb -v outputs; one with usb_modeswitch disabled, the default (Linux?) mode and the 
> alternate mode obtained by sending:
> $ sudo usb_modeswitch -v 12d1 -p 1446 -M 55534243000000000000000000000011060000000100000000000000000000

Thanks.  I note that the device ID is the same after switching
(12d1:14ac) and that the number of endpoints and their layout is
unchanged.

This supports the theory that the exported functions are identical, and
the only difference is a superficial interface layout change for the
ethernet function: 1 => 2 interfaces, different class/subclass/protocol,
CDC functional descriptor.  This is really pointless because we could
have just made the drivers recongnise the layout as used by Windows.

The ethernet function endpoints do not change, and I would be very
surprised if there are any changes in how the firmware handle them:

        bEndpointAddress     0x83  EP 3 IN
        bEndpointAddress     0x84  EP 4 IN
        bEndpointAddress     0x02  EP 2 OUT

You could probably verify this by manually unbinding interface #1 in
"Windows mode" from the option driver and bind it to qmi_wwan instead.

> > Is this a Qualcomm based modem?
>
> As far as I know it is.  Any way for me to tell for sure?

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
 qmicli -d /dev/cdc-wdm0 --dms-get-manufacturer

Just unplug and replug to go back to cdc_ether, or reverse the
bind/unbind. 

If the qmicli command was successful then we should consider changing
this permanently to have access to the QMI device management.


> > Is it likely the device requires 0/1/2/3/4/5, or does any MAC address
> > work as long as it's explicitly set?
>
> Only 0/1/2/3/4/5 seems to work.  I tried 0/5/4/3/2/1 and the address
> the device had in Windows and got no data.

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?

This is my guess on how these things work on the device side.
Guaranteed to be incomplete because I've never seen the firmware code,
most likely inaccurate, and possibly completely wrong:

1) The ethernet addresses are only relevant on the host<->modem link, so
  they do not really matter as long as the host and modem agrees.

2) The modem will use a hardcoded default address (02:50:f3:00:00:00) as
  source address.

3) The modem will learn the host adress either from ARP requests or
  DHCP requests, and use the first adress seen as destination
  "forever".

The host/driver side implications of this are
  * 02:50:f3:00:00:00 cannot be used - the modem will never respond to
     packets from this source
  * only one address is possible - bridging will not work
  * the host address cannot be changed after sending the first ARP or
     DHCP request to the modem


To complicate this a bit, we also have some firmware bugs in circulation
where the firmware
 - advertise 02:50:f3:00:00:00 as default host address in the CDC
   Ethernet functional descriptor
 - use 00:a0:c6:00:00:00 instead of the address learned from the host
 - does't include any ethernet header at all



Bjørn