These bytes are the descriptor data returned by your device in response to GET_DESCRIPTOR request. These data can't appear before the start of control transfer, something is missing in your observation.
The host must start with SETUP transaction [2D]. Then the setup data should follow:
[C3] is DATA0 token, [80 06 00 01 00 00 40 00] is "get descriptor", [DD 94] is CRC16.
This SETUP token must have ACK from your device.
The host then should proceed with IN token.
The device, in response to IN token , should always return the result, which is [12 01 00 02 ........]
"12" means that the descriptor contains 18 bytes of data. The rest you would need to decode, preferably using a better tool, like Teledyne-LeCroy/CATC decoder.
In particular, bytes[8..9] [E6 04] mean the Vendor ID = 0x04E6 (
SCM Microsystems), the next 2 bytes [16..51] means PID=0x5116 - product iD (SCR3310 SmartCard Reader), the rest are other standard fields of your device descriptor.
[D2] is ACK, which is good.
Here is an example of GET_DESCRIPTOR transfer from a LS mouse:
The descriptor data (18 bytes) are split by host into 3 transactions, because of max_packet_size is 8 bytes only for this particular device (Logitech mouse). The whole transfer also has several NAKed transactions, which are hidden.