On Tue, 2013-06-04 at 00:09 +0200, Bjørn Mork wrote:
> Graham Inggs <graham.in...@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.
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?
Also, force-setting the MAC will only work from userspace as long as the
device has unique USB descriptors for that model, and I don't really
trust Huawei to use a separate VID/PID here (since the other reference
to this behavior was the e173-u2, not the mentioned 1820). And I really
don't think we should be poking this sort of thing from ModemManager,
since it's really a hardware/firmware bug. udev rules would be most
appropriate I guess, if modifying cdc-ether is not likely, but like I
said that requires a unique USB descriptor we can rely on :(
Dan
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
