| |
Automatic Activation, Hotplug and UDEV, Configuration
-
bmork
- Posts: 167
- Joined: 15 Mar 2012, 22:47
- Location: Oslo, Norway
Post
by bmork » 12 Feb 2013, 17:53
chrisberesford wrote:Hi,
First post here, so trying to get things right!
I have an E353 from 3 UK. I tried various commands back in the autumn, and have ended up with the id: 12d1:1c05.
Dmesg shows:
[28129.716081] usb 2-4: new high-speed USB device number 5 using ehci_hcd
[28129.849993] usb 2-4: bad CDC descriptors
[28129.850312] usb 2-4: bad CDC descriptors
[28129.850571] usb 2-4: bad CDC descriptors
[28129.850783] usb 2-4: bad CDC descriptors
[28129.850974] usb 2-4: bad CDC descriptors
[28129.851187] usb 2-4: bad CDC descriptors
I think I'm in a similar situation to the chap above.
Code: Select all $ lsusb -v -d 12d1:1c05
Bus 002 Device 005: ID 12d1:1c05 Huawei Technologies Co., Ltd.
Couldn't open device, some information will be missing
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 0x1c05
bcdDevice 1.02
iManufacturer 2
iProduct 1
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 142
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 255 Vendor Specific (MSFT RNDIS?)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x03
line coding and serial state
get/set/clear comm features
I thought that 3 endpoints would make it a RNDIS interface, but now I see that there is code testing for bmCapabilities in the driver:
Code: Select all case USB_CDC_ACM_TYPE:
/* paranoia: disambiguate a "real" vendor-specific
* modem interface from an RNDIS non-modem.
*/
if (rndis) {
struct usb_cdc_acm_descriptor *acm;
acm = (void *) buf;
if (acm->bmCapabilities) {
dev_dbg(&intf->dev,
"ACM capabilities %02x, "
"not really RNDIS?\n",
acm->bmCapabilities);
goto bad_desc;
}
}
break;
So according to that comment we should consider this (and probably also the 2 endpoint variants) as "vendor-specific modem interfaces". I wonder if you get any ttyUSBx port responding to AT commands if you do:
Code: Select all modprobe option
echo 12d1 1c05 >/sys/bus/usb-serial/drivers/option1/new_id
?
Does this add anything to the above problem, and is there any hope of fixing my mistake?
I assume you can use the AT^U2DIAG command to set the modem back to default if you are able to find an AT speaking serial port. It was documented in another thread here recently.
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 12 Feb 2013, 20:32
This is how a real 12d1:1c05 should look:
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C05*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="00", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_modem"
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C05*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="01", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_diag"
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C05*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="02", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_pcui"
Code: Select all Bus 002 Device 006: ID 12d1:1c05 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 0x1c05
bcdDevice 1.02
iManufacturer 2 HUAWEI
iProduct 1 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 131
bNumInterfaces 5
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
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8f EP 15 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8e EP 14 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0f EP 15 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8d EP 13 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0e EP 14 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8c EP 12 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0d EP 13 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0c EP 12 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8b EP 11 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0b EP 11 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8a EP 10 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Return the stick to HiLink mode (12d1:1f01) and try the alternative modeswitch message which with a bit of luck will give the target id 12d1:1001.
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 12 Feb 2013, 21:06
For Bjorn
Here is a similar interface list but look at the bmCapabilities
%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C23&MI_00
%DIAGDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C23&MI_01
%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C23&MI_02
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C23*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="00", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_pcui"
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C23*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="01", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_diag"
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C23*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="02", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_modem"
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C23*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="03", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_pcsc"
Code: Select all Bus 001 Device 030: ID 12d1:1c23 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 0x1c23
bcdDevice 1.02
iManufacturer 2 HUAWEI
iProduct 1 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 249
bNumInterfaces 5
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 255 Vendor Specific (MSFT RNDIS?)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x00
CDC Call Management:
bmCapabilities 0x00
bDataInterface 0
CDC Union:
bMasterInterface 0
bSlaveInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8f EP 15 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0f EP 15 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 255 Vendor Specific (MSFT RNDIS?)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x00
CDC Call Management:
bmCapabilities 0x00
bDataInterface 1
CDC Union:
bMasterInterface 1
bSlaveInterface 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8e EP 14 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0e EP 14 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 255 Vendor Specific (MSFT RNDIS?)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x03
line coding and serial state
get/set/clear comm features
CDC Call Management:
bmCapabilities 0x00
bDataInterface 2
CDC Union:
bMasterInterface 2
bSlaveInterface 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8d EP 13 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8c EP 12 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0d EP 13 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 11 Chip/SmartCard
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 36 21 00 01 00 07 03 00 00 00 c0 12 00 00 40 1f 00 00 04 00 2a 00 00 e7 4c 06 00 6a fe 00 00 00 07 00 00 00 00 00 00 00 b2 07 02 00 0f 01 00 00 ff ff 00 00 00 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0c EP 12 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 8
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8b EP 11 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 8
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8a EP 10 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 4
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0b EP 11 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x89 EP 9 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
-
bmork
- Posts: 167
- Joined: 15 Mar 2012, 22:47
- Location: Oslo, Norway
Post
by bmork » 13 Feb 2013, 10:06
LOM wrote:For Bjorn
Here is a similar interface list but look at the bmCapabilities
%PCUIDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C23&MI_00
%DIAGDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C23&MI_01
%MDMDeviceDesc% = DevInstall, USBCDCACM\VID_12D1&PID_1C23&MI_02
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C23*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="00", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_pcui"
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C23*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="01", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_diag"
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C23*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="02", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_modem"
SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C23*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="03", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_pcsc"
Code: Select all Bus 001 Device 030: ID 12d1:1c23 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 0x1c23
bcdDevice 1.02
iManufacturer 2 HUAWEI
iProduct 1 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 249
bNumInterfaces 5
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 255 Vendor Specific (MSFT RNDIS?)
iInterface 0
CDC Header:
bcdCDC 1.10
CDC ACM:
bmCapabilities 0x00
CDC Call Management:
bmCapabilities 0x00
bDataInterface 0
CDC Union:
bMasterInterface 0
bSlaveInterface 0
OK, looks like we should make some serial drivers deal with this by default. But we cannot just add a match rule to e.g. option because there could be (and likely are) Huawei RNDIS devices using the same class/subclass/protocol combination.
I guess a test similar to the test in cdc_ether is appropriate. I'll see what I can do.
Using usb_modeswitch to dynamically add the device to option should work fine as a workaround in the meantime
EDIT:
I see that there are a number of older Nokia and Samsung phones with 02/02/ff interfaces in the cdc-acm driver. But I am still not sure that is the best place to add these as we really want the speed of the usb_wwan API instead of all the old call management and whatever stuff.
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 13 Feb 2013, 10:36
bmork wrote:
OK, looks like we should make some serial drivers deal with this by default. But we cannot just add a match rule to e.g. option because there could be (and likely are) Huawei RNDIS devices using the same class/subclass/protocol combination.
The 1c23 device is using the cdc_acm driver and it has the 02/02/ff interfaces as chrisberesfords 1c05 so you can not
match on class/subclass/proto in option..
The 1c23 device is btw the only Huawei acm device that I have come across, acm seems to be rarely used by Huawei.
-
bmork
- Posts: 167
- Joined: 15 Mar 2012, 22:47
- Location: Oslo, Norway
Post
by bmork » 13 Feb 2013, 10:50
LOM wrote:bmork wrote:
OK, looks like we should make some serial drivers deal with this by default. But we cannot just add a match rule to e.g. option because there could be (and likely are) Huawei RNDIS devices using the same class/subclass/protocol combination.
The 1c23 device is using the cdc_acm driver and it has the 02/02/ff interfaces as chrisberesfords 1c05 so you can not
match on class/subclass/proto in option..
The 1c23 device is btw the only Huawei acm device that I have come across, acm seems to be rarely used by Huawei.
It does? I still cannot find anything in the cdc-acm driver which would make it support that device (without using /sys/bus/usb/drivers/cdc_acm/new_id ). And the udev rules refer to "ttyUSB*" kernel device names:
Code: Select all SUBSYSTEMS=="usb", ATTRS{modalias}=="usb:v12D1p1C23*", KERNEL=="ttyUSB*", ATTRS{bInterfaceNumber}=="00", ATTRS{bInterfaceProtocol}=="ff", NAME="ttyUSB_utps_pcui"
The cdc-acm driver uses "ttyACM*".
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 13 Feb 2013, 11:11
It uses USBCDCACM according to the windows .inf file, maybe it isn't cdc acm but old fashion serial?
acm is ok to use in the driver name but adding cdc to the name implies that it is a class driver..
jungo names their serial driver juacm, no mention of cdc there.
The 1442 device id which accepted AT cmds for changing device type did also have those 02/02/ff interfaces.
-
bmork
- Posts: 167
- Joined: 15 Mar 2012, 22:47
- Location: Oslo, Norway
Post
by bmork » 13 Feb 2013, 11:58
LOM wrote:It uses USBCDCACM according to the windows .inf file, maybe it isn't cdc acm but old fashion serial?
Right, I missed that.
But there really are not that many ways to do bulk serial over USB. The main difference between all the different serial USB drivers is the control signalling. Different setup, flow control signalling etc. None of this matters much to the normal USB mobile broadband modem.
The reason the option driver is used for so many devices is that it is extremely flexible and has few strict requirements. It is also fast, because it ignores all the single character tty stuff. If a device can do serial over bulk endpoints then it will work with that driver.
acm is ok to use in the driver name but adding cdc to the name implies that it is a class driver..
jungo names their serial driver juacm, no mention of cdc there.
The 1442 device id which accepted AT cmds for changing device type did also have those 02/02/ff interfaces.
The cdc-acm class driver will most likely do the job for the function with 3 endpoints, but it will not work with any of the 2 endpoint functions. The probe function has this:
Code: Select all if (control_interface == data_interface) {
/* some broken devices designed for windows work this way */
dev_warn(&intf->dev,"Control and data interfaces are not separated!\n");
combined_interfaces = 1;
/* a popular other OS doesn't use it */
quirks |= NO_CAP_LINE;
if (data_interface->cur_altsetting->desc.bNumEndpoints != 3) {
dev_err(&intf->dev, "This needs exactly 3 endpoints\n");
return -EINVAL;
}
and I think there is a reason for that.
So we could let cdc-acm handle the 3-endpoint function and some other driver handle the other functions. But I don't think there is any good reason to complicate things like that. We can just use the same driver for all the functions and completely ignore any possible ACM functionality. We don't need it and we don't know whether it works.
I would be surprised if the firmware handles these functions any differently than all the ones with a ff class. The difference is most likely only in the device descriptor. Let's just ignore that 
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 13 Feb 2013, 12:45
I am a bit slow today, should of course had seen that the linux datacard rules has the interfaces as ttyUSB and not ttyACM but I got a brain fart when looking at the driver names.
I don't think Huawei uses 02/02/ff for anything else than serial comms so it should be safe to add this interface type into the option driver.
-
bmork
- Posts: 167
- Joined: 15 Mar 2012, 22:47
- Location: Oslo, Norway
Post
by bmork » 13 Feb 2013, 14:24
LOM wrote:I am a bit slow today, should of course had seen that the linux datacard rules has the interfaces as ttyUSB and not ttyACM but I got a brain fart when looking at the driver names.
I don't think Huawei uses 02/02/ff for anything else than serial comms so it should be safe to add this interface type into the option driver.
Huawei is a big company making lots of odd devices. I am still worried that they could have some USB wlan or ethernet device using RNDIS.
For now, I think I'll propose adding device specific matching to the option driver for the 3 PIDs we have seen. I don't want to propose CDC descriptor parsing in a generic driver, and there does not seem to be any other way to distinguish the 3 endpoint serial 02/02/ff functions from RNDIS functions (except of course the Microsoft magic 0xee string descriptor, but using that is even less appropriate I believe)
So we keep it simple for now. We can always reconsider adding more generic code if more devices like these show up.
-
LOM
- Posts: 1404
- Joined: 11 Jul 2012, 15:14
- Location: Koh Samui, TH
Post
by LOM » 13 Feb 2013, 15:58
ok, can you then include 12d1:1441 as well?
Code: Select all usb_modeswitch -v 0x12d1 -p 0x1f01
-M "55534243123456780000000000000011062000000000000200000000000000"
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=12d1 ProdID=1441 Rev= 1.02
S: Manufacturer=HUAWEI
S: Product=HUAWEI HiLink
C:* #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=(none)
E: Ad=8f(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=06 Prot=00 Driver=(none)
E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 2 Alt= 0 #EPs= 2 Cls=02(comm.) Sub=02 Prot=ff Driver=(none)
E: Ad=8d(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=0e(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 3 Alt= 0 #EPs= 2 Cls=02(comm.) Sub=02 Prot=ff Driver=(none)
E: Ad=8c(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=0d(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
I:* If#= 4 Alt= 0 #EPs= 2 Cls=02(comm.) Sub=02 Prot=ff Driver=(none)
E: Ad=8b(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=0c(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
it is the same device as 12d1:14db but using another of Microsoft sniffed messages, it basically adds 3 serial interfaces
to the already present ecm interfaces and changes the PID.
Code: Select all usb_modeswitch -v 0x12d1 -p 0x1f01 -V 0x12d1 -P 0x14db
-M "55534243123456780000000000000a11062000000000000100000000000000"
T: Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 3 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=02(comm.) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=12d1 ProdID=14db Rev= 1.02
S: Manufacturer=HUAWEI
S: Product=HUAWEI HiLink
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 1 Cls=02(comm.) Sub=06 Prot=00 Driver=(none)
E: Ad=8f(I) Atr=03(Int.) MxPS= 64 Ivl=2ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=06 Prot=00 Driver=(none)
E: Ad=8e(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=0f(O) Atr=02(Bulk) MxPS= 512 Ivl=4ms
-
bmork
- Posts: 167
- Joined: 15 Mar 2012, 22:47
- Location: Oslo, Norway
Post
by bmork » 13 Feb 2013, 16:30
LOM wrote:ok, can you then include 12d1:1441 as well?
Will do.
I see that the number of different devices is increasing, proving my simple strategy wrong already
Bjørn
-
chrisberesford
- Posts: 6
- Joined: 12 Feb 2013, 16:31
Post
by chrisberesford » 14 Feb 2013, 05:09
Thanks for helping!
I'll try and do as you asked above, and post up the results.
How can I change the device back to HiLink mode?
Thanks, and sorry for the stupid questions!
Chris
-
bmork
- Posts: 167
- Joined: 15 Mar 2012, 22:47
- Location: Oslo, Norway
Post
by bmork » 14 Feb 2013, 08:44
chrisberesford wrote:Thanks for helping!
I'll try and do as you asked above, and post up the results.
How can I change the device back to HiLink mode?
If one of the serial ports responds to AT commands , then you could try the command given here:
http://www.draisberghof.de/usb_modeswit ... 295&p=8670
Somewhat risky, but I guess there isn't much to lose... Let us know how everything goes.
If no serial port is an AT command port, then I don't know how to use them.
-
chrisberesford
- Posts: 6
- Joined: 12 Feb 2013, 16:31
Post
by chrisberesford » 27 Feb 2013, 16:08
I tried the dongle again:
[ 1487.558846] usb 1-4: USB disconnect, device number 3
[ 1512.176080] usb 1-4: new high-speed USB device number 4 using ehci_hcd
[ 1512.310532] usb 1-4: bad CDC descriptors
[ 1512.312575] usb 1-4: bad CDC descriptors
[ 1512.312930] usb 1-4: bad CDC descriptors
[ 1512.315939] usb 1-4: bad CDC descriptors
[ 1512.319141] usb 1-4: bad CDC descriptors
[ 1512.324150] usb 1-4: bad CDC descriptors
And no ttyUSB or ttyA* entries in /dev/
I read here: http://blog.phoenixhaven.net/2012/09/11 ... alup-modem
about the lack of serial ports, and tried to add using the suggested command, but I can't find any reference to the usb-serial module on my system. Is it possible to install as a driver or something?
Thanks again
Chris
|
|
