i have checked in a patch to distinguish between dupacks and windowupdates.
it should even handle the case correctly when you have
1: ACK win==1
2: DUPACK#1 to 1 win==1
3: WindowUpdate win==2
4: DUPACK#2 to 1 win==2
> Ethereal wasn't the only tool that saw things that way
Wouldnt surprise me at all.
If you are referring to commerical network analyzers, they usually
have so pathetically bad
tcp analysis features so i dont think they can even detect a dup ack
in the first place.
(they usually can not even find retransmissions properly)
Please test the new code i just checked in.
Also look at : http://wiki.ethereal.com/TcpPduTime?action=highlight&value=tcp.pdu.time
which shows a very useful feature when looking for performance
problems related to tcp retransmission timeouts.
Unfortunately other analyzers are so incredibly primitive that they
cans plot or measure things like this.
best regards
ronnie sahlberg
On Wed, 1 Dec 2004 19:37:29 -0500, Donnie Hale
<lists-ethereal@xxxxxxxxxxxxxx> wrote:
> In reviewing some captures today, Ethereal reported some packets as [TCP Dup
> ACK ...]. When I see that, I generally think there's some kind of loss in
> the environment. However, in looking more closely at the frames, we were
> able to determine that these weren't indicators of loss but instead of the
> receive window being opened after previously being shrunk. As I understand
> it, this is legal TCP behavior - resending a just-sent ACK with a different
> window size to indicate that the receiver's window readiness has changed.
>
> Ethereal wasn't the only tool that saw things that way, though tcptrace
> seems to have understood what these packets were.
>
> Assuming our interpretation is correct, would there be a way to improve
> Ethereal's handling of those kind of packets so that they don't look on the
> surface like loss indicators?
>
> Thanks,
>
> Donnie
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
