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. Bjørn _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list