First of all I have written this stack so there are no other machines and drivers involved PC or otherwise. It is all me. The code is not new and has been running well in many applications for a few years. My device is attempting to connect to another on an unused port. It is expected to fail. I do not RST such attempts so the SYN rightfully retransmits. I was expecting it to be tagged as a retransmission. The "spurious" qualifier here I believe is incorrect. My understanding is that it would be spurious had there been an ACK to the original SYN. As you can see there are no ACK flags. Can you point to the deficiency with my SYN packet? Here is the capture (for as long as it will sit there for free).
asked 31 Aug '16, 09:53  bscloutier edited 31 Aug '16, 10:41  sindy |
2 Answers:
It looks like the TCP dissector is a bit overzealous considering this a spurious retransmission. It tests this then decides it's spurious, which is also true when all is 0. I think it should add the condition an ACK was seen. You should file a bug report with this capture file and description of the problem. It can then be addressed. answered 31 Aug '16, 11:01  Jaap ♦ I have submitted Bug 12800 for this. (31 Aug '16, 11:21) bscloutier |
Here is @Jasper's explanation. In short, in the special case of SYN packet, the meaning of the "spurious retransmission" expert label differs from its meaning for a mid-session packet. So "it's not a bug, it's a feature". To publish a capture, you need to upload it to Cloudshark or to some general file sharing service and put a link to it here (editing the original Question with the link is usually better than putting the link into a Comment). answered 31 Aug '16, 10:38 sindy I read this before. I can understand the argument as to whether or not a repeated SYN is a "retransmission". That is how I look at it. I am retransmitting on a SYN timeout. But the "spurious" tag here doesn't sit right. There is no previous connection or ACK'ing associated with this socket. "Spurious" here makes it sound like it really is "unnecessary" and that I shouldn't bother retrying. Oh, and the link to the capture should now be in the question. (31 Aug '16, 10:49) bscloutier
Yes, it is there (and I've made a bit of editing on it), but the essence is that there is nothing wrong about the capture itself. It is just that no one has yet become upset enough to ask for a change of the TCP expert label used for a repeated SYN. As @Jasper explains (instead of @SYN-bit, the real author of that piece of code), a "retransmission" has a certain meaning in TCP, so the adjective "spurious", which distinguishes "meaningless" retransmissions from "meaningful" ones, has been used also for the "repeated" (to avoid the word "retransmitted") SYNs, but to emphasize that these are not retransmissions in the reserved meaning of the word, @SYN-bit has re-used the label "spurious retransmission". If it twists your eyes too much, file a bug. (31 Aug '16, 11:05) sindy I'm not upset at all. Wireshark has helped tremendously in developing this TCP stack. So I pay attention to these things. My first thought always is that there is something wrong with my packets/procedures. Honestly, that has been the case many times. So in this case I was more "confused" than "upset". I filed a low-priority bug report so no one else should be confused by this in the future. This stack is quite involved. It handles a lot including TLS v1.2 and there is no third party code including the cryptography. Runs on a Renesas RX600 MPU. If it is broken, it is my fault. So I pay attention to details and do appreciate Wireshark! Thanks! (31 Aug '16, 11:30) bscloutier |
You can you share a capture in a publicly accessible spot, e.g. CloudShark, Google Drive, DropBox etc. and then edit your question with a link to the capture.
Post editted. Thanks.