On Wed, 2011-12-14 at 10:36 -0600, Dan Williams wrote:
> 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.
Ignore me, I mixed up netdev and linux-usb in my head.
> 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
