How does Wireshark calculate the TCP stream index number? I'm used to seeing the first TCP packet in a trace file have a TCP stream index of 0. However, I have a trace file in which the first TCP packet has a TCP stream index of 6. There are 10,000 packets in the file, 5,619 of which are TCP. The TCP stream index numbers run from 6 to 196, with many gaps in the sequence. According to Statistic > Conversations, there are 37 TCP conversations in this file. If I apply “tcp” as a display filter, save only the displayed packets, and then load this new trace file, the TCP stream index numbers range sequentially from 0 to 36 with no gaps. Is there some reason why the presence of other non-TCP traffic in the trace file should cause the TCP stream index number to have gaps in the sequence? If this is not expected behavior, I'll file a bug report at bugzilla.wireshark.org. asked 15 Jul '11, 12:48  Jim Aragon |
2 Answers:
It is something that bothered me too, but Sake (who implemented the stream index) gave me a perfect explanation for this: the stream index is shown only for TCP flows, but it is incremented with each conversation, even if it is a UDP conversation. If you take a closer look you'll see that the gaps between each TCP stream number have UDP conversations that "use" the hidden numbers (usually DNS request/answer pairs). I don't remember the full details of why it is done this way but as far as I remember Sake had performance reasons, because otherwise he'd have to keep track of new TCP sessions starting while there already is a conversation counter that he could use for this. answered 15 Jul '11, 13:01  Jasper ♦♦ The concept makes sense, but I still can't figure out the numbering. The first TCP packet is #355, with stream index 6, so there should be 6 conversations that start ahead of it in the trace file: 0-5. I selected the first UDP packet, clicked "Follow UDP stream," marked the displayed packets, and moved on to the next unmarked UDP packet. So far, I've marked 12 UDP conversations that start before the first TCP conversation and I'm only up to conversations starting with packet 41. (15 Jul '11, 13:43) Jim Aragon I plead guilty :-) Yes, it was me who did this. And as Jasper said, I did not want to introduce other variables while there is a perfectly usable conversation index available. Since there are quite a few questions being asked about the numbering, I'm not sure I made the right decision. The fact is that not all UDP protocols keep track of state with the conversation system. So the numbering of the TCP sessions all depend on the other protocols present in the file. And the numbering can differ between versions of Wireshark when protocol dissectors start using conversations in newer versions. (15 Jul '11, 14:06) SYN-bit ♦♦ Would it be (much) better to have the TCP stream indexes start from 0 and increase by one, no matter what? It will add a little to the memory footprint of Wireshark (and will probably also cost a bit of extra CPU cycles)? (15 Jul '11, 14:08) SYN-bit ♦♦ Would it be better? Yes. Much better? Don't know if I'd go that far. Sometimes, after selecting "Follow TCP stream," I've moved to the next TCP stream by leaving the display filter in place, overwriting the number, and clicking "Apply." Sometimes it works; sometimes I find out that there is no such TCP stream. I don't know if too many people would use that functionality. (15 Jul '11, 14:31) Jim Aragon In my example, with 37 streams in the file, I think it could be useful to know that stream 36, for example, is the last one, rather than seeing stream number 131 (out of 37 streams) and wondering where I am. (15 Jul '11, 14:33) Jim Aragon 2 OK, I changed it in SVN 38056, there is now a separate index for tcp streams, which means it will monotonously increase by 1 for each new TCP session. As this is new behavior, it will be included in 1.8.x and not in 1.6.x. If you want you can use an automated build or the next 1.7.x release. (15 Jul '11, 16:44) SYN-bit ♦♦ Thanks, Sake. I tried 38056. Looks good. (15 Jul '11, 19:59) Jim Aragon The change in 38056 unfortunately broke "Follow TCP Stream" functionality. This got fixed in SVN 38065. (17 Jul '11, 04:14) SYN-bit ♦♦ showing 5 of 8 show 3 more comments |
Hi Jim, I was wondering if you could help me with interpreting some captures I did... I am very new to Wireshark and I got a doozy of a network issue on my hands. Thanks so much, Michael answered 29 Mar '16, 09:19  Michael-YYZ I appreciate this is your first visit to the site, but this is not a forum it's a Q&A site and your "answer" is not an answer to this question, or even suitable as a separate question. If you have a particular capture that you would like help with, then please posts a new question, along with a link to the capture, describing the issue as fully as possible. (29 Mar '16, 10:43) grahamb ♦ |
how does conversation or stream index incerement . is it the same as a new SOCKEt call in in linux ?
Every new SYN will create a new stream index. The index will be increased by one, starting from zero.