Hy, i'm not talking about absolute seq/ack number, i'm referring that
ethereal doesn't count that frame:
Into the raw data for the fist and second packet:
For the 1st packet: 97 18 cd f6
For the second packet: 97 18 cd f7
The difference is "one", but ethereal show:
*captured*
1 0.000000 10.0.0.50 10.0.0.2 TCP 1057 > 7777 [SYN] Seq=0 Ack=0
2 0.000077 10.0.0.2 10.0.0.50 TCP 7777 > 1057 [RST, ACK] Seq=0
Ack=0
This is wrong, the "Syn" has to be counted as "one" byte to be ACKed... And
it should look like:
*simulated*
10.0.0.50 --> 10.0.0.2 1057-->7777 [SYN] SEQ=0, ACK=0
10.0.0.2 --> 10.0.0.50 7777-->1057 [RST,ACK] SEQ=0, ACK=1
But it doesn't, ethereal in packet summary show it to be still set to ACK=0
into the second packet; while in the raw data the increment is reported...
I hope to have explained better my doubt.
-----Messaggio originale-----
Da: Olivier Biot [mailto:ethereal@xxxxxxxxxx]
Inviato: mercoledì 17 novembre 2004 22.12
A: "Camp0s"
Cc: Ethereal user support
Oggetto: Re: [Ethereal-users] May be a small visualization bug in 10.6
version
It's a feature.
If you want to see the *absolute* sequence numbers, go to Edit, Preferences,
click on "Protocols", and select the TCP protocol. Uncheck the tick mark on
"use relative sequence numbers".
Best regards,
Olivier
----- Original Message -----
From: Camp0s
Hy, i'm new to this list and i'm using Ethereal in school lab since 3 weeks,
well i don't know for sure, but during a test on what happen when i telnet
to a machine at a port without a service behind (eg 7777) a get i incorrect
SEQ->ACK numbers in visualization, in brief, the request should be:
[snip]
For the 1st packet: 97 18 cd f6
For the second packet: 97 18 cd f7
... And the difference is correctly 1, as ACK should be incremented.
What do you think ? Did i do some mistake, misunderstood, it's a bug ?