pythonusbwiresharkpyusbpyscard

USB - Is there an initial handshake between host and device?

I'm capturing USB traffic using Wireshark on a smart card reader. When I connect to the reader using PyScard, some packets are sent back and forth using bulk operations before I send any APDU just by establishing the connection.

I have read here that there is an initial handshake between a USB device and the host and I wonder if that is what I see while sniffing.

Using wireshark, I get the following:

  1. Bulk out (host to device):

First packet

  1. Bulk out (device to host):

Second packet

  1. Bulk in (host to device):

third

  1. Bulk in (device to host):

Fourth packet

These four packets are sent 2-3 times and then I can sniff the messages I send using PyScard.

My goal here is to reproduce the communication between the reader and the host by using only USB communications. So:

  1. Is there an initial handshake in USB communications?

  2. Is that what I'm capturing?

  3. How can I reproduce this USB communications?

Thanks <3


Edit 14/03/2018 - Additional information following David Grayson's answer

What I am capturing here is not the part of "Get Device Descriptor", etc. This happens when I try to print the device's details and Wireshark recognises and labels the packets as so.

I'm aware of the weird operations but it is what I'm getting from wireshark. The interpretation I've been doing is that they're request-response pairs: the host sends something using bulk out endpoint and then asks to read the answer by using bulk in endpoint when it is ready to do so. I have absolutely no idea, it's just what it looks to me.

>> lsusb -v

Bus 001 Device 002: ID 0bda:0165 Realtek Semiconductor Corp. 
Couldn't open device, some information will be missing
Device Descriptor:

    bLength                
    bDescriptorType         1
    bcdUSB               2.00
    bDeviceClass            0 (Defined at Interface level)
    bDeviceSubClass         0 
    bDeviceProtocol         0 
    bMaxPacketSize0        64
    idVendor           0x0bda Realtek Semiconductor Corp.
    idProduct          0x0165 
    bcdDevice           61.23
    iManufacturer           1 
    iProduct                6 
    iSerial                 3 
    bNumConfigurations      1

Configuration Descriptor:
        bLength                 9
        bDescriptorType         2
        wTotalLength           93
        bNumInterfaces          1
        bConfigurationValue     1
        iConfiguration          4 
        bmAttributes         0xa0
          (Bus Powered)
          Remote Wakeup
        MaxPower              500mA
        
Interface Descriptor:
    bLength                 9
    bDescriptorType         4
    bInterfaceNumber        0
    bAlternateSetting       0
    bNumEndpoints           3
    bInterfaceClass        11 Chip/SmartCard
    bInterfaceSubClass      0 
    bInterfaceProtocol      0 
    iInterface              6 
    
ChipCard Interface Descriptor:
    bLength                54
    bDescriptorType        33
    bcdCCID              1.10  (Warning: Only accurate for version 1.0)
    nMaxSlotIndex           0
    bVoltageSupport         7  5.0V 3.0V 1.8V 
    dwProtocols             3  T=0 T=1
    dwDefaultClock       3750
    dwMaxiumumClock      7500
    bNumClockSupported      0
    dwDataRate          10080 bps
    dwMaxDataRate      312500 bps
    bNumDataRatesSupp.      0
    dwMaxIFSD             254
    dwSyncProtocols  00000000 
    dwMechanical     00000000 
    dwFeatures       00010030
    Auto clock change
    Auto baud rate change
    TPDU level exchange
    dwMaxCCIDMsgLen       271
    bClassGetResponse      00
    bClassEnvelope         00
    wlcdLayout           none
    bPINSupport             0 
    bMaxCCIDBusySlots       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               8
    
Endpoint Descriptor:
    bLength                 7
    bDescriptorType         5
    bEndpointAddress     0x05  EP 5 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     0x86  EP 6 IN
    bmAttributes            2
      Transfer Type            Bulk
      Synch Type               None
      Usage Type               Data
    wMaxPacketSize     0x0200  1x 512 bytes
    bInterval               0

(The screenshots are ok, they look alike but they're not the same)

Solution

  • The initial handshake consists of controls transfers like "Get Device Descriptor", "Get Configuration Descriptor" and "Set Address", which are defined in Chapter 9 of the USB 2.0 specification.

    The initial handshake usually does not have any bulk transfers, but it is possible that your device uses a driver which wants to do some bulk transfers when it gets initialized. Since it is a smart card reader, I imagine your operating system has some driver that sends commands to it in order to see if any smart cards are connected, and those commands could very well be implemented with bulk transfers instead of control transfers. To learn more about these commands, you would need to find the documentation of the USB class that your device implements and/or the driver that is sending these commands.

    The description of your bulk traffic is confusing. The term "Out" always means "Host to device" so it cannot mean "Device to host" also. The term "In" always means "Device to host" so it cannot mean "Host to device" also. You posted two duplicate screenshots.

    To get better responses in the future, I think you should include a dump of your device's descriptors (lsusb -v), improve your description of the traffic, say what endpoints the traffic was seen on, and also say what operating system you are using and give any information you have about the drivers that are attached to your device.