Re: Serial ports for Septentrio USB GNSS receiver
On 10.06.2013 20:19, Bjørn Mork wrote: The cdc-acm driver cannot handle those ports, but a more forgiving generic driver can. I don't recommend it for normal use because it abuses the option driver, but Ben could do a simple test like this: echo 2 /sys/bus/usb/devices/usbportname/bConfigurationValue modprobe option echo 152a 8230 /sys/bus/usb-serial/drivers/option1/new_id Unless I missed something, this should result in two /dev/ttyUSBx serial devices. Before plugging in the receiver, there's ttyUSB0 and ttyUSB1 from another usb/serial converter device that I can't remove. After plugging in, dmesg says: usb 3-2: new full-speed USB device number 2 using uhci_hcd usb 3-2: New USB device found, idVendor=152a, idProduct=8230 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-2: Product: Septentrio USB Device usb 3-2: Manufacturer: Septentrio cdc_acm 3-2:1.0: ttyACM0: USB ACM device usbcore: registered new interface driver cdc_acm cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters and ttyACM0 appears. # echo 2 /sys/bus/usb/devices/usbportname/bConfigurationValue usbcore: registered new interface driver cdc_ether usb 3-2: bad CDC descriptors usb 3-2: bad CDC descriptors usbcore: registered new interface driver rndis_host usb 3-2: bad CDC descriptors usb 3-2: bad CDC descriptors usbcore: registered new interface driver rndis_wlan ttyACM0 is gone and no new ttyUSB* appear. # modprobe option usbcore: registered new interface driver option usbserial: USB Serial support registered for GSM modem (1-port) # echo 152a 8230 /sys/bus/usb-serial/drivers/option1/new_id option 3-2:2.0: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB2 option 3-2:2.1: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB3 option 3-2:2.2: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB4 option 3-2:2.3: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB5 ttyUSB2 is dead ttyUSB3 works and is connected to a port named USB1 on the receiver ttyUSB4 is dead ttyUSB5 works and is connected to a port named USB2 on the receiver usb-devices now shows: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 P: Vendor=152a ProdID=8230 Rev=01.10 S: Manufacturer=Septentrio S: Product=Septentrio USB Device C: #Ifs= 4 Cfg#= 2 Atr=c0 MxPwr=2mA I: If#= 0 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option I guess this device is worth a new serial driver of its own in case that works? Or should we create a generic driver for 02/02/ff serial devices (using the inverse of the logic in drivers/net/usb/cdc_ether.c: usbnet_generic_cdc_bind to avoid RNDIS devices)? A few modems with such ports have been added to option, but a generic solution might be better. I obviously don't know, but would be very happy to supply further information! thanks, ben -- Ben Adler Universität Hamburg MIN-Fakultät FB Informatik, AB TAMS Vogt-Kölln-Strasse 30 22527 Hamburg Tel +49 40 42883 2504 Fax +49 40 42883 2397 Mob +49 160 858 0660 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serial ports for Septentrio USB GNSS receiver
Ben Adler ad...@informatik.uni-hamburg.de writes: On 10.06.2013 20:19, Bjørn Mork wrote: The cdc-acm driver cannot handle those ports, but a more forgiving generic driver can. I don't recommend it for normal use because it abuses the option driver, but Ben could do a simple test like this: echo 2 /sys/bus/usb/devices/usbportname/bConfigurationValue modprobe option echo 152a 8230 /sys/bus/usb-serial/drivers/option1/new_id Unless I missed something, this should result in two /dev/ttyUSBx serial devices. Before plugging in the receiver, there's ttyUSB0 and ttyUSB1 from another usb/serial converter device that I can't remove. Thanks a lot for your attention to detail. That comment prevented unnecessary questions about those devices. After plugging in, dmesg says: usb 3-2: new full-speed USB device number 2 using uhci_hcd usb 3-2: New USB device found, idVendor=152a, idProduct=8230 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 3-2: Product: Septentrio USB Device usb 3-2: Manufacturer: Septentrio cdc_acm 3-2:1.0: ttyACM0: USB ACM device usbcore: registered new interface driver cdc_acm cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters and ttyACM0 appears. # echo 2 /sys/bus/usb/devices/usbportname/bConfigurationValue usbcore: registered new interface driver cdc_ether usb 3-2: bad CDC descriptors usb 3-2: bad CDC descriptors usbcore: registered new interface driver rndis_host usb 3-2: bad CDC descriptors usb 3-2: bad CDC descriptors usbcore: registered new interface driver rndis_wlan ttyACM0 is gone and no new ttyUSB* appear. Yup, that's expected. The bad CDC descriptors warnings should probably be silcened? They are not very useful to any end user, and only mean that these these drivers probed the device and found that it wasn't a RNDIS device. Which isn't any error, but just the way this is supposed to work. # modprobe option usbcore: registered new interface driver option usbserial: USB Serial support registered for GSM modem (1-port) # echo 152a 8230 /sys/bus/usb-serial/drivers/option1/new_id option 3-2:2.0: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB2 option 3-2:2.1: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB3 option 3-2:2.2: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB4 option 3-2:2.3: GSM modem (1-port) converter detected usb 3-2: GSM modem (1-port) converter now attached to ttyUSB5 ttyUSB2 is dead ttyUSB3 works and is connected to a port named USB1 on the receiver ttyUSB4 is dead ttyUSB5 works and is connected to a port named USB2 on the receiver Thanks for verifying this. I didn't expect the ttyUSB2 and ttyUSB4 devices. Thought the driver would refuse the two interfaces with no endpoints. Obviously wrong. But the fact that ttyUSB3 and ttyUSB5 works fine is what we need to know. usb-devices now shows: T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 P: Vendor=152a ProdID=8230 Rev=01.10 S: Manufacturer=Septentrio S: Product=Septentrio USB Device C: #Ifs= 4 Cfg#= 2 Atr=c0 MxPwr=2mA I: If#= 0 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option I: If#= 2 Alt= 0 #EPs= 0 Cls=02(commc) Sub=02 Prot=ff Driver=option I: If#= 3 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=ff Driver=option I guess this device is worth a new serial driver of its own in case that works? Or should we create a generic driver for 02/02/ff serial devices (using the inverse of the logic in drivers/net/usb/cdc_ether.c: usbnet_generic_cdc_bind to avoid RNDIS devices)? A few modems with such ports have been added to option, but a generic solution might be better. I obviously don't know, but would be very happy to supply further information! I am starting to lean towards the generic 02/02/ff serial driver, but I'm not currently able to do the work so I should probably not propose it... If you are looking for a nice place to start playing with the kernel, then this is the perfect project :) You have the hardware, which makes testing a lot easier. And the driver will be very small. Some of the simpler drivers in driver/usb/serial/ can be used as examples. The main challenge will be handling the separate data interface, because you do want to match on the control interface and parse the functional descriptors there. cdc_acm and cdc_ether are examples on how to do that, but the method will have to be adapted to the usb-serial framework. Anyway, there is no harm in using the method you used above until a more suitable serial driver is found or developed. It's just not a generic solution suitable for inclusion in the kernel (in particular because of the non-functional
Re: Serial ports for Septentrio USB GNSS receiver
On Mon, Jun 10, 2013 at 06:56:30PM +0200, Ben Adler wrote: Hello Greg, thanks for getting back to me! I'm using a http://www.septentrio.com/products/receivers/asterx2i-oem INS/GNSS receiver. When connected via USB to a windows-host, there's two (or even three, don't remember exactly) virtual serial ports to talk to it. Why do you want to talk to the other ports? What is on those connections? They're all serial ports, used to issue commands to the receiver (in binary or ascii form) and receive data at different intervals (again, binary or ascii). Which messages exactly are accepted or sent on which (virtual) port at which interval can be configured. That's not what the USB device descriptors you provided below show. They look like a normal cdc-acm device, so we are (according to the USB-IF specification), supposed to export to userspace a single device that can be used to communicate with it. When connected to a 3.8.0-19-generic #30-Ubuntu SMP i686 GNU/Linux system, I only see /dev/ttyACM0. I'd really like to get access to the second virtual com port, so I tried setting Why? These receivers are rather complex systems and use of multiple (virtual) serial ports is often necessary. For example, to use a very precise positioning mode like differential GPS or even RTK (Real-Time-Kinematic GPS), differential correction data has to be streamed to the receiver (from another, stationary GNSS receiver). This MUST be done on a separate port, because otherwise the receiver is unable to discriminate command input from differential correction input. Odd, that's not what a cdc-acm device is supposed to be for, but oh well :) But, again, the device isn't exposing multiple devices to the operating system at all, that must be something Windows is doing with a custom driver for the device. It also is often convenient to access the same receiver from multiple processes using different ports. Multiple processes can access the same device port just fine, that's how they should always work (although if you are doing command/response type things, it can get messy with multiple applications.) In essence, I'd simply like to be able to use any or all of /dev/ttyACM* to talk to the device. You are getting the one port to talk to the device properly already, but it seems it is lying to the OS about what it really is :( [lsusb output] Even though I don't really understand the interfaces and endpoints, I get the impression there's multiple CDC-Data interfaces. Yes, there are, but the cdc-acm driver binds to them all (you can see this by running 'usbdevices' from the usbutils package. T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 P: Vendor=152a ProdID=8230 Rev=01.10 S: Manufacturer=Septentrio S: Product=Septentrio USB Device C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=2mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm I can confirm :) How can this be changed? How can I use them? The network should connect to the device just fine through the single port, right? I don't understand, which network are you referring to? There is no network connection for this device. Ok, my mistake, I thought this was a network device. You're going to have to possibly unbind the cdc-acm driver from the device, and either talk directly to it using libusb, or write a custom kernel driver to expose the different ports properly. I would suggest contacting the company to get the specs on how to talk to the device in order to be able to do this. Also, is there a way to influence the latency? As I'm using the receiver's data for flight control, I'd prefer to achieve low latency in data transfer from receiver-host on at least one port. I see the Transfer Type for most endpoints is bulk, not interrupt, but maybe there's a few tricks to make bulk-transfers faster? Right now I'm seeing latencies between 5 and 70ms. There is no difference in speed or latency between the bulk and interrupt endpoints, it just is how the data is transferred from the USB device (they really are the same, just that interrupt is smaller packets more often, and bulk is larger packets whenever there is some data.) USB devices are well known for having latency issues, that's due to the cheap chip in them, plus the usb protocol overhead, plus whatever is on the other side of the USB device sending data. It almost never is the host OS issue here. Thanks for the explanation! Meanwhile I've also realized that 95% of the packets I receive are exactly 60 bytes in length, and sometimes (not always) I see latencies similar to this (in milliseconds): 34 6 44 5 51 8 20 7 So I could also imagine that there is a buffer (probably of 61size119 bytes) that only gets flushed once its full. Is there, by any chance, a 64
Re: Serial ports for Septentrio USB GNSS receiver
On Mon, 10 Jun 2013, Greg KH wrote: [lsusb output] The lsusb output in the original email message showed two configurations. Config 1 exposes a single port, whereas config 2 exposes two ports (although it is vendor-specific, not CDC-ACM). Even though I don't really understand the interfaces and endpoints, I get the impression there's multiple CDC-Data interfaces. Yes, there are, but the cdc-acm driver binds to them all (you can see this by running 'usbdevices' from the usbutils package. T: Bus=03 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=02(commc) Sub=00 Prot=00 MxPS= 8 #Cfgs= 2 P: Vendor=152a ProdID=8230 Rev=01.10 S: Manufacturer=Septentrio S: Product=Septentrio USB Device C: #Ifs= 2 Cfg#= 1 Atr=c0 MxPwr=2mA I: If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=02 Prot=01 Driver=cdc_acm I: If#= 1 Alt= 0 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_acm This output confirms that there are two configurations, although only one of them is shown. By default, config 1 is installed. I can confirm :) How can this be changed? It is possible to switch to config 2 manually or by a pre-programmed script. The necessary command is very simple: echo 2 /sys/bus/usb/devices/3-2/bConfigurationValue Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serial ports for Septentrio USB GNSS receiver
Greg KH gre...@linuxfoundation.org writes: On Mon, Jun 10, 2013 at 06:56:30PM +0200, Ben Adler wrote: Hello Greg, thanks for getting back to me! I'm using a http://www.septentrio.com/products/receivers/asterx2i-oem INS/GNSS receiver. When connected via USB to a windows-host, there's two (or even three, don't remember exactly) virtual serial ports to talk to it. Why do you want to talk to the other ports? What is on those connections? They're all serial ports, used to issue commands to the receiver (in binary or ascii form) and receive data at different intervals (again, binary or ascii). Which messages exactly are accepted or sent on which (virtual) port at which interval can be configured. That's not what the USB device descriptors you provided below show. They look like a normal cdc-acm device, so we are (according to the USB-IF specification), supposed to export to userspace a single device that can be used to communicate with it. Note that the lsusb output showed a second configuration with 2 vendor specific ACM functions (only 2 bulk endpoints and protocol = 0xff) instead of the single standard CDC ACM function. This is probably the configuration used by the Windows host. The cdc-acm driver cannot handle those ports, but a more forgiving generic driver can. I don't recommend it for normal use because it abuses the option driver, but Ben could do a simple test like this: echo 2 /sys/bus/usb/devices/usbportname/bConfigurationValue modprobe option echo 152a 8230 /sys/bus/usb-serial/drivers/option1/new_id Unless I missed something, this should result in two /dev/ttyUSBx serial devices. I guess this device is worth a new serial driver of its own in case that works? Or should we create a generic driver for 02/02/ff serial devices (using the inverse of the logic in drivers/net/usb/cdc_ether.c: usbnet_generic_cdc_bind to avoid RNDIS devices)? A few modems with such ports have been added to option, but a generic solution might be better. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Serial ports for Septentrio USB GNSS receiver
On Thu, May 30, 2013 at 04:00:17PM +0200, Ben Adler wrote: Hello list! I'm using a http://www.septentrio.com/products/receivers/asterx2i-oem INS/GNSS receiver. When connected via USB to a windows-host, there's two (or even three, don't remember exactly) virtual serial ports to talk to it. Why do you want to talk to the other ports? What is on those connections? When connected to a 3.8.0-19-generic #30-Ubuntu SMP i686 GNU/Linux system, I only see /dev/ttyACM0. I'd really like to get access to the second virtual com port, so I tried setting Why? options usbserial vendor=0x152a product=0x8230 Ick, no, don't do that. It's an acm device, use the correct driver for it. usbserial_generic 3-2:1.0: Generic device with no bulk out, not allowed. usbserial_generic: probe of 3-2:1.0 failed with error -5 Exactly, it's not a normal generic usb serial device :) usb 3-2: generic converter now attached to ttyUSB0 ttyUSB0 does work for communicating with the device, but there's no second port (this trick did work with some NovAtel receivers). Is there a way to make the other virtual COM port appear? # lsusb -d 152a:8230 -v Bus 003 Device 002: ID 152a:8230 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x152a idProduct 0x8230 bcdDevice1.10 iManufacturer 1 Septentrio iProduct2 Septentrio USB Device iSerial 0 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 91 bNumInterfaces 4 bConfigurationValue 2 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol255 Vendor Specific (MSFT RNDIS?) iInterface 0 CDC Header: bcdCDC 1.01 CDC ACM: bmCapabilities 0x0e connection notifications sends break line coding and serial state Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol255 Vendor specific iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol255 Vendor Specific (MSFT RNDIS?) iInterface 0 CDC Header: bcdCDC 1.01 CDC ACM: bmCapabilities 0x0e connection notifications sends break line coding and serial state Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol255 Vendor specific iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval
Serial ports for Septentrio USB GNSS receiver
Hello list! I'm using a http://www.septentrio.com/products/receivers/asterx2i-oem INS/GNSS receiver. When connected via USB to a windows-host, there's two (or even three, don't remember exactly) virtual serial ports to talk to it. When connected to a 3.8.0-19-generic #30-Ubuntu SMP i686 GNU/Linux system, I only see /dev/ttyACM0. I'd really like to get access to the second virtual com port, so I tried setting options usbserial vendor=0x152a product=0x8230 in /etc/modprobe.d/septentrio.conf. Doing this, I get /dev/ttyUSB0 - dmesg says: usbcore: registered new interface driver usbserial usbcore: registered new interface driver usbserial_generic usbserial: USB Serial support registered for generic usbserial_generic 3-2:1.0: Generic device with no bulk out, not allowed. usbserial_generic: probe of 3-2:1.0 failed with error -5 usbserial_generic 3-2:1.1: The generic usb-serial driver is only for testing and one-off prototypes. usbserial_generic 3-2:1.1: Tell linux-usb@vger.kernel.org to add your device to a proper driver. usbserial_generic 3-2:1.1: generic converter detected usb 3-2: generic converter now attached to ttyUSB0 ttyUSB0 does work for communicating with the device, but there's no second port (this trick did work with some NovAtel receivers). Is there a way to make the other virtual COM port appear? # lsusb -d 152a:8230 -v Bus 003 Device 002: ID 152a:8230 Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass2 Communications bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x152a idProduct 0x8230 bcdDevice1.10 iManufacturer 1 Septentrio iProduct2 Septentrio USB Device iSerial 0 bNumConfigurations 2 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 91 bNumInterfaces 4 bConfigurationValue 2 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol255 Vendor Specific (MSFT RNDIS?) iInterface 0 CDC Header: bcdCDC 1.01 CDC ACM: bmCapabilities 0x0e connection notifications sends break line coding and serial state Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol255 Vendor specific iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol255 Vendor Specific (MSFT RNDIS?) iInterface 0 CDC Header: bcdCDC 1.01 CDC ACM: bmCapabilities 0x0e connection notifications sends break line coding and serial state Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass10 CDC Data bInterfaceSubClass 0 Unused bInterfaceProtocol255 Vendor specific iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes2 Transfer TypeBulk Synch Type
