 | 1 | initial version |
Though the math is difficult to follow given that the tcp_len values can only be inferred from the seq# sent by the 194. endpoint (and those are not displayed in those segments labeled with "Continuation"), it looks like heavy packet loss (on the order of 3*mss somewhere between frames 24 and 27). As a suggestion (only) you may want to modify the 'len' column to display the tcp_len value (or add that column). Another suggestion is to disable relative sequence numbering. It makes the numbers bigger but they eventually becomes easier to follow, at a glance.
That being said, there are a few odd items of note with your screen capture.
One 'odd" thing that seems noteworthy is that there is ~1.5+sec between segment 24 and 27. The 194. sent 3*mss worth of segments to the 83. endpoint, I would expect that the local retx timer would've expired for N number of those segments. It's unusual for a local retx timer to be set on the order of seconds (linux default for first retx is 200ms - IIRC), but without knowing the configuration of these endpoints I suppose it could be configured at higher (possibly non-default) values.
Regardless .. there is no indication that proper recovery is occurring on the 194. endpoint. We see that the ACK number from the 83. endpoint continues to be '1,' as if there are NO segments seen from the 194. endpoint.
That being said .. there MAY be SACK option information populated in the segments sent from the 83. endpoint, but those are not visible in your output. (I would expect to see truncated information at the far right of the "Info" field if SLE<>SRE info was contained in the segments from the 83. endpoint).
