| Bug ID |
12259
|
| Summary |
tcp RTO calculation incorrect
|
| Product |
Wireshark
|
| Version |
2.0.2
|
| Hardware |
All
|
| OS |
All
|
| Status |
UNCONFIRMED
|
| Severity |
Major
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
wireshark 2.0.1 and older
--
i noted that in some circumstances wireshark/tshark calculates rto time from
the wrong segment.
This is a capture from my company's production environment :
https://www.cloudshark.org/captures/ca907de31560
looking at the trace the frames sent from server 10.1.1.2 were lost :
frame 90 is retransmitted with frame 112 (but rto is based on delta from frame
104)
frame 91 is retransmitted with frame 120 (but rto is based on delta from frame
104)
frame 92 is retransmitted with frame 128 (but rto is based on delta from frame
124)
to find the original segment i apply a filter with tcp.seq and tcp.nxtseq of
the retrasmitted packet and use frame.time_delta_display to show the right rto.
Is it right or am i misunderstanding something about RTO ?
shouldn't rto timer start when the packet is sent?
regards
Guido
You are receiving this mail because:
- You are watching all bug changes.
