![]() Now, in combination with the first code change, repeated SYN packets to a closed port will show up like in the screen shot. The question was now, why were repeated SYN packets marked as “spurious retransmissions”? The change Sake introduced to “packet-tcp.c” was to mark repeated SYN and FIN packets as retransmissions, which wasn’t the case before. Maybe the acknowledge packet got lost, so the sender could not know that the packet got through and assumed it was lost. To find out why it does that you would need a capture close to the sender to see what the situation is at that location. If you’re seeing spurious retransmissions it means that the sender thought packets were lost and sent them again, even though the receiver sent an acknowledge packet for it. There is a bug report where the patch was mentioned at “Needless” probably doesn’t sound technically weird enough, so in papers about those retransmissions they were labeled “spurious”. What does “Spurious Retransmission” mean?īasically “Spurious Retransmission” means that data was sent again that the receiver had already acknowledged, which is something that we used to call “needless retransmission” in our own expert system. The older change was to add an expert message when a segment was seen that was transmitting data older than the last segment that the receiver had requested. It turned out that two changes had been made that explained the screen shot above, one by the Joe from Cloudshark, and one by Sake: So I fired up my SVN tool to get the latest code revision and took a look at “packet-tcp.c” in the dissector directory. It turned out that Landi didn’t get those expert messages in his version of Wireshark, so I guessed that it had to be something that was changed pretty recently, since I was using the 1.11 developer version (for verifying some bug reports that had been closed) and he was on 1.10 stable. Well, my English is not so bad, but I had no clue what this kind of retransmission was supposed to be (or even what the word “spurious” meant :-)), especially in a SYN packet, which had never been marked as a retransmission before: Tracking the code change So I did, and while we were talking about what the SSL dissector was doing I saw a new TCP expert message I had never seen before: “TCP Spurious Retransmission”. ![]() Today, while doing a lot of testing of my trace handling code as well as in preparation for the upcoming Sharkfest 2013, I got a trace sample from Landi that he wanted me to take a look at because he wondered about some SSL decoding stuff. ![]() I am new to this low level stuff and will appreciate your assistance very much. ![]() What causes that? And what can I do to prevent that? I am receiving a webhook from an API with a Jetty server, but connection is reset. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |