Huawei E173 12d1:1446 alias 12d1:1436 alias 12d1:140c

[Bjørn Mork]

Thomas Schäfer <tschaefer at t-online.de> writes:

> Hi, 
>
> I know the huawei E173 is not the newest modem and it is already supported by 
> linux - at least in modem/ppp-mode. Also the E173 seems to have a lot of 
> different brandings.I talk here about the O2-Version in Germany (telefonica ).
>
> Here was a discussion about the correct targetID/device-mode:
>
>               http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=657
>
> At this time there was no qmi_wwan module available. 
> There were only some contradictions between the recommendation from huawei for 
> linux and the practice in the windows-driver.
>
> Now we have qmi_wwan and it works in one point better than the cdc_ether.
>
> While the cdc_ether -mode (with ID 12d1:1436) has a bug with the mac-address, 
> the qmi_wwan-interface works as expected.

I believe this is because you use different firmware modes for cdc_ether
and qmi_wwan, don't you?  The drivers should behave the same given the
same USB descriptors.  The firmware bug is a simple matter of mixing up
the MAC address in the iMACAddress string descriptor causing both ends
of the link to use the same address.  The "Windows mode" probably does
not have any CDC Ethernet functional descriptor and therefore qmi_wwan
ends up using a random address, which works.

The fact that such a bug is possible demonstrates why OS specific modes
is a bad idea:  The Windows mode is the only mode guaranteed to work.
Kudos to Huawei for trying to accommodate Linux by adapting the firmware
to existing Linux drivers, but I believe that approach was a bad choice
when it ended up using different modes for Windows and for Linux.

We are much better off with Linux drivers trying to mimic enough of
Windows to make the hardware work the same way on both systems.

> To remember the steps with cdc_ether:
>
> at^ndisdup=1,1,"apn"
> OK
> ifconfig wwan0 hw ether 00:01:02:03:04:05  /// workaround for a bug
> dhcpcd wwan0
>
> dhcpcd -k wwan0
> at^ndisdup=1,0
>
> With qmi I used the old perl testscript qmi-ifupdown.
> A test with modemmanager was not successful, because it crashed with segfault. 
> The reason for this could be to much wrong interfaces.
> For tests I did: 
>  echo "12d1 140c" >/sys/bus/usb/drivers/qmi_wwan/new_id
>
> My question is, is it useful to change the general behavior of this device?
> ppp still works, but wwan interfaces may be a better choice. And the wwan-
> interface with cdc_ether is buggy.

IMHO, this device should be handled by qmi_wwan so that the QMI channel
is made available to userspace.  If I understand correctly, the "Windows
mode" is currently not handled by any driver so that can just be added
with no bad effects?

But I don't think we can change the Huawei entry in cdc_ether.  It is
very generic, and there are most likely non-QMI device correctly matched
by it as well.  So the alternative for this particular device would be
to change just the usb_modeswitch defaults.

And I don't know if that is too wise, either.  It is an old device and
most users will probably "know how it works" and be rightfully annoyed
if we change any default behaviour.  And Huawei, like many other modem
vendors, tend to reuse their product IDs for lots of very different
devices. So verifying that such a change doesn't break anything is next
to impossible.

The best we can do is probably 
- add the "windows mode" to qmi_wwan
- provide hints (in the usb_modeswitch config maybe?) on how this non
  default mode can be used, as well as why you might want to do that

Do you have the full "lsusb -v" listings for all modes of this device?
And do you happen to know exactly what Windows matches on (i.e. is it a
device specific VID/PID/MI or something else)?  You can find this
somewhere in the Windows device manager.


Bjørn