Enrico Mioso <[email protected]> writes:
> Hi !! I'm writing you privately, only because I can't find out the
> proper list address, but if you reply including the list in CC, I'll
> adapt myself.
>
> I'm writing you a post regarding this forum thread:
> http://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?f=3&t=1280&view=previous
>
> Being a visually impaired user, makes for me it very unconfortable to
> deal with forums and such.
I can understand that. I much prefer mailing lists myself.
> but here's the good news - I have the device, and I can do with it
> whatever I like!
Great!
> I saw the problem where deriving from missing informations about it.
> But I have it and can work on it as long as I desire. My objective is
> understanding, not necessarily making it work.
> Here is the lsusb. the command-set of the device is pretty
> huawei-style, but you can find also some commands coming from ICERA.
> the device interface is pretty inconsistent: you can use management
> commands from both command-sets, and the device doesn't guarantee any
> coherency.
> An example?
> NDIS:
> - you can handle them using icera commands:
> at%ipdpact=...
> - or using huawei command set
> at^ndisdup=...
>
> And that's pretty strange.
I believe this is normal for Huawei devices. They use chipsets and
firmware from different vendors, but try their best to implement a
common set of Huawei specific commands on top this. So you have
"standard" Huawei AT commands like at^ndisdup both in Qualcomm and Icera
based devices, while still having access to the chipset specific
interfaces.
Unfortunately, firmware is firmware, and there will be different sets of
bugs in these alternative interfaces. So it's not obvious which one is
best to use. And as you note: Coherency can be a problem. It seems
they sometimes store device state in the "Huawei specific" part of the
firmware, which of course leads to syncronization problems.
Thanks for the detailed information. Knowing for sure that this modem
is Icera based is very useful.
> the same applies for the virtual CD interface and other aspects. Most
> of the case, I suppose the device answers you OK just out of the box.
> thank you!
>
>
>
> Bus 001 Device 067: ID 12d1:14ae Huawei Technologies Co., Ltd. Device
> Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 0 (Defined at Interface level)
> bDeviceSubClass 0
> bDeviceProtocol 0
> bMaxPacketSize0 64
> idVendor 0x12d1 Huawei Technologies Co., Ltd.
> idProduct 0x14ae
> bcdDevice 1.02
> iManufacturer 3 Vodafone Group (Huawei)
> iProduct 2 Vodafone Mobile Broadband (Huawei)
> iSerial 4 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 199
> bNumInterfaces 4
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0x80
> (Bus Powered)
> MaxPower 500mA
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 0
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 255 Vendor Specific Subclass
> bInterfaceProtocol 255 Vendor Specific Protocol
> iInterface 0
> ** UNRECOGNIZED: 05 24 00 10 01
> ** UNRECOGNIZED: 04 24 02 07
> ** UNRECOGNIZED: 05 24 01 03 00
> ** UNRECOGNIZED: 05 24 06 00 00
Those look like CDC functional descriptors even if the class is claimed
to be vendor specific. So that's
CDC Header: 1.10
CDC ACM:
bmCapabilities 0x07
sends break
line coding and serial state
get/set/clear comm features
CDC Call Management:
bmCapabilities 0x03
call management
use DataInterface
bDataInterface 0
CDC Union:
bMasterInterface 0
bSlaveInterface 0
Not that any of this matters to us, I believe.
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 0
> bNumEndpoints 1
> bInterfaceClass 2 Communications
> bInterfaceSubClass 6 Ethernet Networking
> bInterfaceProtocol 255
> iInterface 0
> CDC Header:
> bcdCDC 1.10
> CDC Ethernet:
> iMacAddress 1 001e101f0001
> bmEthernetStatistics 0x0000000f
> wMaxSegmentSize 1514
> wNumberMCFilters 0x0003
> bNumberPowerFilters 1
> CDC Union:
> bMasterInterface 1
> bSlaveInterface 1
> Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x83 EP 3 IN
> bmAttributes 3
> Transfer Type Interrupt
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0040 1x 64 bytes
> bInterval 5
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 1
> bAlternateSetting 1
> bNumEndpoints 3
> bInterfaceClass 2 Communications
> bInterfaceSubClass 6 Ethernet Networking
> bInterfaceProtocol 255
> iInterface 0
Yes, so this was the part of the picture we were missing in the
usb-devices output. There is an alternate setting for the CDC Ethernet
like interface.
This is one of the reasons I dislike the usb-devices script. It seems
to present the same view as the the old /proc/bus/usb/devices file or
the new (but debugfs only) /sys/kernel/debug/usb/devices file, but some
extremely important parts are missing. Without alternate interface
settings and configurations the output is more misleading than useful
IMHO. We'd be better off if this script did not exist at all.
Some day I will write the proper usb-devices replacement, unless someone
else beats me to it. It shouldn't be much more than alternative output
for lsusb.
> Interface Descriptor:
> bLength 9
> bDescriptorType 4
> bInterfaceNumber 2
> bAlternateSetting 0
> bNumEndpoints 3
> bInterfaceClass 255 Vendor Specific Class
> bInterfaceSubClass 255 Vendor Specific Subclass
> bInterfaceProtocol 255 Vendor Specific Protocol
> iInterface 0
> ** UNRECOGNIZED: 05 24 00 10 01
> ** UNRECOGNIZED: 04 24 02 07
> ** UNRECOGNIZED: 05 24 01 03 02
> ** UNRECOGNIZED: 05 24 06 02 02
So this is identical to interface #0, except that it refers to interface #2
Enrico Mioso <[email protected]> writes:
> Even here you can observe the BAD CDC descriptor error - after the cdc_ether
> driver tried to attach to the device.
Yes, I don't think the cdc_ether likes this kind of combined control and
data interface. A proper CDC Ethernet function would have a separate
data interface and a CDC Union functional descriptor tying the control
and data interfaces together. That's what the driver expects. Here we
instead have a CDC Union descriptor pointing to the same interface for
both.
I guess we can add a workaround for this to cdc_ether.c, just like we
recently did for cdc_ncm.c for other types of Huawei devices with the
same problem.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
