["Keith French" <keithfrench@xxxxxxxxxxxxxxx>]

Ronnie,
    Thanks for a very interesting & useful reply.

Keith French.
----- Original Message -----
From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
To: "Ethereal user support" <ethereal-users@xxxxxxxxxxxx>
Sent: Wednesday, April 07, 2004 10:28 AM
Subject: Re: [Ethereal-users] TCP Sequence Number Differs From Sniffer Basic


>
> >----- 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
>
> _______________________________________________
> Ethereal-users mailing list
> Ethereal-users@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-users


---
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