On Tue, 2011-12-13 at 05:52 +0100, Bjørn Mork wrote:
> Alex Hermann <alex@xxxxxxxxx> writes:
> > On Wednesday 07 December 2011 15:43:45 Bjørn Mork wrote:
> >> Alex Hermann <alex-lists@xxxxxxxxx> writes:
> >> > the E398 shares an usb id with the E353, but seems to use different
> >> > interfaces. The ones already present in the option driver don't autoload the
> >> > driver for this device.
> >> > Bus 002 Device 008: ID 12d1:1506 Huawei Technologies Co., Ltd. E398
> >> > LTE/UMTS/GSM Modem/Networkcard
> >>
> >> Do you happen to know what usb_modeswitch command you used to switch the
> >> device to this mode? I happen to ha a similar device (E392) using the
> >> exact same USB IDs, but I have not seen any NCM descriptor there (yet).
> >
> > I just copied one from a similar device, as it worked for ppp, i looked
> > no further.
>
> But do you get full speed with ppp? I have been unable to push more
> than 8 Mbps upstream using ppp. Using the ethernet emulation I can
> consistently get 25+ Mbps upstream.
>
> > MessageContent="55534243123456780000000000000011062000000100000000000000000000"
>
> Thanks, that's what I'm using as well.
>
> I finally took the time to sniff on Windows, and found that that driver
> uses "55534243000000000000000000000011060000000100000000000000000000".
> Which causes an interesting effect: The CDC descriptors disappear and
> the control and data interfaces are merged into one.
>
> So they do actually provide a "Linux" mode and a "Windows" mode.
>
> I wondered if maybe the problem was that the "Linux" mode wasn't very
> well tested. But creating a minimalistic driver for the "Windows" mode
> showed that it had exactly the same behaviour. I guess that supports
> my assumption that everything behind the endpoints is exactly the same
> independent of descriptors.
>
> I also looked through a Windows session to see if there were any magic
> commands there, but there were none. Only what was expected: Common
> AT commands, including the AT+CPIN="xxxx", and a few QMI commands to
> actually start the session.
>
> So I started the little harder job of adding QMI to an usbnet driver
> (after first trying to Gobi driver, which immediately hung my laptop - I
> didn't continue that way. Don't think the "dual serial/net" interface
> is a good idea, and the driver has been rejected for reasons unknown to
> me).
>
> Anyway, adding QMI paid off. After sending a QMI_WDS "start" message,
> the device is working perfectly as any other USB CDC ECM device,
> supporting DHCP for address configuration and forwarding traffic at
> speeds up to 70/26 Mbps.
Where did you post the rough-draft driver to? I didn't see it on netdev
but I may have just missed it.
Dan
> It seems as if these devices cannot be configured for ethernet operation
> using only AT commands. You have to register with the QMI system.
>
>
>
> >
> >> The Windows driver indicates that this is a CDC NCM (?) interface:
> >
> >> It would be extremely interesting to know if you are able to use the
> >> cdc_ncm class driver on this card, though. It might need some
> >> modifications to allow it to load for a vendor specific interface.
> >> Haven't looket at the details.
> >
> > I tried to get it to work with the following patch. I allowed the driver to
> > continue even if the device was already bound, just to see what would happen.
> > It did seem to parse the descriptor just fine, but the device didn't accept
> > any AT+NDISDUP commands on the serial devices.
> >
> > diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> > index f06fb78..6470e66 100644
> > --- a/drivers/net/usb/cdc_ncm.c
> > +++ b/drivers/net/usb/cdc_ncm.c
> > @@ -145,6 +145,10 @@ static const struct usb_device_id cdc_devs[] = {
> > USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
> > .driver_info = (unsigned long)&cdc_ncm_info,
> > },
> > + { USB_DEVICE_AND_INTERFACE_INFO(0x12d1,
> > + 0x1506, 0xff, 0x02, 0x16),
> > + .driver_info = (unsigned long)&cdc_ncm_info,
> > + }, /* E398 */
> > {
> > },
> > };
> > @@ -545,7 +549,7 @@ advance:
> >
> > /* claim interfaces, if any */
> > temp = usb_driver_claim_interface(driver, ctx->data, dev);
> > - if (temp)
> > + if (temp && temp!= -EBUSY)
> > goto error;
> >
> > iface_no = ctx->data->cur_altsetting->desc.bInterfaceNumber;
>
>
> I just posted my first draft of a working CDC ECM based driver with QMI
> support. It's not very polished, and I assume that there will be
> hundreds of bugs to fix before it can go anywhere, but if you're brave
> you can try combining the QMI support from it with the cdc_ncm. That
> might do it.
>
>
>
> Bjørn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
