Enrico Mioso <mrkiko.rs@xxxxxxxxx> 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 <mrkiko.rs@xxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
