On Tue, 2013-06-04 at 00:33 +0200, Bjørn Mork wrote:
> Dan Williams <d...@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?
Yeah, we'd probably end up shipping the udev rule with MM if that's how
we end up going. Even though it's not really an MM specific hack, it's
general. Which might be a candidate for usb_modeswitch I suppose, but
if that's the case I'd rather just have usb_modeswitch change the rule
to use the Windows mode instead of hacking the MAC address. Just like
ACPI, we should be doing what Windows does here, since all the "linux
mode" stuff seems half-assed and badly thought out hacks to work with a
specific version of the kernel or userspace when we can clearly change
things and make them better.
Dan
_______________________________________________
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
