TCP network trace raises questions

[amalg]

Capturing packets between Android Smart Card reader app and the VPCD driver running on Windows 11, I noticed some traffic that raised questions. Here is the first few packets of traffic. The data is listed in numbered sequence where > indicates an outbound packet from VPCD to reader and < indicates an inbound packet from reader to VPCD;

01 >00 01 04
02 <00 0F 3B 8A 80 01 00 31  C1 73 C8 40 00 00 90 00 90
03 >00 01 04
04 <00 0F 3B 8A 80 01 00 31  C1 73 C8 40 00 00 90 00 90
05 >00 01 02 00 01 04
06 <00 0F 3B 8A 80 01 00 31  C1 73 C8 40 00 00 90 00 90
07 >00 01 02 00 01 04
08 <00 0F 3B 8A 80 01 00 31  C1 73 C8 40 00 00 90 00 90
09 >00 01 04
10 <00 0F 3B 8A 80 01 00 31  C1 73 C8 40 00 00 90 00 90
11 >00 01 02 00 01 04
12 <00 0F 3B 8A 80 01 00 31  C1 73 C8 40 00 00 90 00 90
13 >00 10 00 A4 04 00 0B A0  00 00 03 97 43 49 44 5F 01 00
14 <00 02 6A 82

I am noticing two things;

• The request for ATR is repeated a total of 6 times before the first APDU is actually sent from the Windows OS after card inserted has been asserted by VPCD
• The request for ATR appears malformed in packets 05, 07 and 11. Specifically the 16 bit length indicates 1 byte but 4 bytes are sent.

My questions are;

• Is the constant querying for ATR from VPCD designed as a form of no-op or keep-alive check of the TCP connection's status?
• Are packets 05, 07, and 11 indeed malformed ATR requests which remote-reader on Android is truncating to the last byte "04" due to the preceding specified length indicating a single byte, and serendipitously still interpreting as an ATR request?

[amalg]

@mildsunrise this is data captured from virtualsmartcard release version 0.8 (prior to your recent contribution). Considering your changes to calculating and sending the length (size) bytes and payload in a single call to sendall(), do you think this may have inadvertently solved this problem? I have no tools nor skill enough to compile and test or I would :/

[amalg]

Oh wow.. when I said I didn't have the skill, I was dead on.

This is not an issue. There are simply two separate control codes sent;

00 01 02 - reset, which generates no response from the remote reader 00 01 04 - get atr

Sorry. I wish github allowed reverting back the complete history of the universe to pretend like I never posted this issue.