>----- Original Message -----
>From: Keith French
>To: Ethereal-Users
>Sent: Wednesday, April 07, 2004 7:03 PM
>Subject: [Ethereal-users] TCP Sequence Number Differs From Sniffer Basic
>
>
>In Ethereal V 0.10.3 the TCP header seems to report differently to the same
trace when viewed in Sniffer Basic (V4.50). As an example Sniffer Basic
>displays (in the TCP three way handshake to set up the session) :-
>
>Source Port
>Destination Port
>Initial Sequence Number (first frame) or Sequence Number (subsequent
frames)
>Next Expected Seq Number
>Acknowledgement Number (subsequent frames only)
>Data Offset etc
>
>
>The same viewed with Ethereal shows:-
>
>Source Port
>Destination Port
>Sequence Number (but not the ISN)
>Acknowledgement Number (on subsequent frames only not initial one).
>Header Length (same number of bytes as Data Offset -seems reasonable)
>
Technically there is nothing in the tcp protocol header called
InitialSequenceNumber, the TCP protocol only has SequenceNumbers.
InitialSequenceNumber is only a special word used in some documentation
describing the SequenceNumber used in SYN packets.
So it is the same thing really. These fields are always SequenceNumbers,
ISN is just a paper construct in some books to distinguish
SN in non-SYN packets from SN in SYN packets.
>
>When you get to the first packet in the session (e.g. FTP) Ethereal does
show the Next Sequence Number field in the header, but the values for all
>sequence numbers are totally different to Sniffer Basic.
>
Ethereal only prints the synthetic field NextSequencenumber if the length of
the TCP segment is >0 bytes.
If length of data in the segment is 0 bytes then the next sequence number is
semi-meaningless.
>E.G.
>For the same packet (first in FTP transfer)
>
>Sniffer Basic:-
>
>Sequence Number : 3065059825
>Next Expected Seq Number : 3065059867
>Acknowledgement Number : 481399856
>
>Ethereal:-
>
>Sequence Number : 1
>Next Expected Seq Number : 43
>Acknowledgement Number : 1
Since the sequence number values themself lack any specific semantic meaning
other than their values relative to other segments in the same stream
ethereal by default will translate them to values relative to the initial
segment seen in the capture.
This makes the numbers smaller and much easier to read by eyeballing.
Studying two sequence numbers 5000 and 6500 it is trivial and quick to
eyeball them and in a fraction of seconds see that the number of bytes in
the sequence number space between these segments are 1500 bytes. since the
values are so small they are easilably viewabable by just looking at them.
Eyeballing the true sequence numbers example 165793482 and 165794982 is
MUCH more difficult even if the delte here as well is only 1500 bytes.
It takes much more effort and longer time, often with the need to write them
down on paper.
That is a waste of time and user unfriendly since other then the relative
difference between them they lack any semantic meaning.
If Sniffer does not translate them to relative easily managble numbers that
is a useability bug you should report to them.
>
>I have looked in the preferences under Protocols/TCP but cannot see
anything that might suggest a different way of reporting the same data.
>
You did not search enough but were close.
Under TCP preference options, disable the preference setting "Relative
sequence numbers and window scaling" to make ethereal display sequence and
ack numbers in the same broken way as some other broken tool do.
By disabling this prefs option Ethereal will not even show you any
meaningful window size values anymore either, probably making it even more
similar to thos other broken tools that are out there.
Pity those poor users, it is said those tools cant even detect
retransmissions properly. How incredibly useless and broken.
>
>Any ideas what is happening?
>
Yes. disable the option above and ethereal will become as broken when
displaying the sequence and ack numbers as some other tools are by design..
:-)
>Keith French
>
:-) thanks for using ethereal. please dont use other tools, it is likely
they are broken and can not be fixed.
best regards
ronnie sahlberg
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.648 / Virus Database: 415 - Release Date: 31/03/2004
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users