Re: [MM] Huawei E1820 and NDISDUP

[Bjørn Mork <bjorn mork no>]

Graham Inggs <graham inggs uct ac za> writes:

> My Huawei E1820 works fine with ModemManager in PPP mode.
> I tried to get it to work with NDISDUP.  I added the following lines to 
> plugins/huawei/77-mm-huawei-net-port-types.rules:
>
> # Huawei E1820 firmware 11.831.03.00.00
> SUBSYSTEMS=="usb", ATTRS{bInterfaceClass}=="02", 
> ATTRS{bInterfaceSubClass}=="06",ATTRS{bInterfaceProtocol}=="ff", ENV{ID_MM_HUAWEI_NDISDUP_SUPPORTED}="1"
>
> ModemManager was then able to connect using the AT^NDISDUP command.
> I received an IP address and DNS settings, but I didn't seem to be getting any traffic over the connection.
>
> I noticed the following line in the output of dmesg:
>
> [13317.359566] cdc_ether 2-5:1.1 wwan0: CDC: unexpected notification 01!

This is completely unrelated and harmless message. Mostly useless driver
noise, but it does make me wonder what management protocol we have
encapsulated here.  Is this a Qualcomm based modem?

> I searched for this error and came across the following post:
>
> http://linux.derkeiler.com/Newsgroups/comp.os.linux.hardware/2011-09/msg00042.html
>
> Sure enough, changing the MAC address of wwan0 to 00:01:02:03:04:05 solved the problem!
> I am using an Ubuntu 3.8 kernel.  The modem works fine with AT^NDISDUP in Windows.
> Is this a problem with the cdc_ether driver, or something that could be fixed in ModemManager?

This is really a firmware bug. The firmware USB descriptors tell the
host to use the device MAC address, and you end up with a link using the
same address on both ends.  Which won't work. Because the addresses are
made up anyway, you can change it to pretty much anything you want.

We recently added a workaround for this bug in qmi_wwan (by using a
random address):
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/net/usb/qmi_wwan.c?id=cc6ba5fdaabea7a7b28de3ba1e0fe54d92232fe5

In theory a similar patch could be applied to cdc_ether, but I not sure
it would be safe there.  The cdc_ether driver is used for a much, much
more diverse set of devices. And I'd hate to see a non-buggy device fail
due to a workaround for a firmware bug this stupid...

And it is perfectly possibly to work around this in userspace, like you
do.



Bjørn