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.
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
