Re: [MM] Huawei E1820 and NDISDUP

[Bjørn Mork <bjorn mork no>]

Dan Williams <dcbw redhat com> writes:
> On Mon, 2013-06-03 at 21:31 +0000, Graham Inggs wrote:
> > 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!
> >
> > 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?
>
> Wow, that's awesome.  I think Bjorn might have some input here, but it
> might include swearing. 

:)

> Quick question, in Windows does the device have
> the 00/1/2/3/4/5 hardware address?

Windows is probably not seeing the descriptors we see.  A firmware bug
like this can only exist because it is limited to the "Linux mode" of
these devices.  One of the reasons why I hate^Wdislike the idea of
special Linux firmware modes...

It would be interesting to know how this device appear if the modeswitch
command message is changed to

 MessageContent="55534243000000000000000000000011060000000100000000000000000000"

> This is something that should be fixed in the kernel, or via udev rules,
> but it's not something that ModemManager should ever have to deal with.
> It's a hardware bug, or really a stupid firmware that probably doesn't
> follow the cdc_ether specification to communicate it's MAC address to
> the host.  We might be able to put some workarounds in the kernel
> drivers, otherwise we'll have to work around it in userspace with udev
> rules I think.

An udev rule sounds good.  That would keep the user in control.  I am
not sure adding the workaround in qmi_wwan was such a great idea.

But I guess the real challenge is to have the workaround automatically
applied. Putting it in the kernel is the simple solution to that.  What
are the alternatives?  Could an udev rule be included with ModemManager?


Bjørn