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