diff options
| author | Ronnie Sahlberg <ronnie_sahlberg@ozemail.com.au> | 2003-10-28 08:50:39 +0000 |
|---|---|---|
| committer | Ronnie Sahlberg <ronnie_sahlberg@ozemail.com.au> | 2003-10-28 08:50:39 +0000 |
| commit | a185c70b18ceab4f11cc100932c393300655625d (patch) | |
| tree | 861ba16ee2d07e4c4dde9e1fdb170e9b6fcae6fb /packet-tcp.c | |
| parent | c68a7d7cb15b8fede442eef7b1ec19d616ecc10e (diff) | |
| download | wireshark-a185c70b18ceab4f11cc100932c393300655625d.tar.gz wireshark-a185c70b18ceab4f11cc100932c393300655625d.tar.bz2 wireshark-a185c70b18ceab4f11cc100932c393300655625d.zip | |
Full duplex analyzers that capture each direction of a link with a separate NIC will lose the time integrity between the two NICs more often than one might expect.
It is thus relatively common that a data segment and its ACK being swapped in the capture file.
Therefore, drop the condition that a segment must not have been acked yet in the detection of OutOfOrder segments.
Second, fix a bug where we didnt keep track of the ack numbers properly for relative sequence number analysis.
svn path=/trunk/; revision=8800
Diffstat (limited to 'packet-tcp.c')
| -rw-r--r-- | packet-tcp.c | 15 |
1 files changed, 12 insertions, 3 deletions
diff --git a/packet-tcp.c b/packet-tcp.c index 234eb5c9a0..da7717cf0e 100644 --- a/packet-tcp.c +++ b/packet-tcp.c @@ -1,7 +1,7 @@ /* packet-tcp.c * Routines for TCP packet disassembly * - * $Id: packet-tcp.c,v 1.210 2003/10/27 19:34:03 guy Exp $ + * $Id: packet-tcp.c,v 1.211 2003/10/28 08:50:39 sahlberg Exp $ * * Ethereal - Network traffic analyzer * By Gerald Combs <gerald@ethereal.com> @@ -551,7 +551,7 @@ tcp_analyze_sequence_number(packet_info *pinfo, guint32 seq, guint32 ack, guint3 num2_acks=tcpd->num2_acks; tnp=&tcpd->pdu_seq2; base_seq=(tcp_relative_seq && (ual1==NULL))?seq:tcpd->base_seq1; - base_ack=(tcp_relative_seq && (ual2==NULL))?seq:tcpd->base_seq2; + base_ack=(tcp_relative_seq && (ual2==NULL))?ack:tcpd->base_seq2; win_scale=tcpd->win_scale1; } else { ual1=tcpd->ual2; @@ -566,7 +566,7 @@ tcp_analyze_sequence_number(packet_info *pinfo, guint32 seq, guint32 ack, guint3 num2_acks=tcpd->num1_acks; tnp=&tcpd->pdu_seq1; base_seq=(tcp_relative_seq && (ual1==NULL))?seq:tcpd->base_seq2; - base_ack=(tcp_relative_seq && (ual2==NULL))?seq:tcpd->base_seq1; + base_ack=(tcp_relative_seq && (ual2==NULL))?ack:tcpd->base_seq1; win_scale=tcpd->win_scale2; } @@ -757,10 +757,17 @@ printf(" Frame:%d seq:%d nseq:%d time:%d.%09d ack:%d:%d\n",u->frame,u->seq,u->n * 4 there were no dupacks in the opposite direction. */ outoforder=TRUE; +#ifdef REMOVED + /* dont do this test. For full-duplex capture devices that + * capture in both directions using two NICs it is more common + * than one would expect for this to happen since they often + * lose the time integrity between the two NICs + */ /* 1 has it already been ACKed ? */ if(LT_SEQ(seq,ack1)){ outoforder=FALSE; } +#endif /* 2 have we seen this segment before ? */ for(tu=ual1;tu;tu=tu->next){ if((tu->frame)&&(tu->seq==seq)){ @@ -1056,6 +1063,7 @@ ack_finished: tcpd->num1_acks=num1_acks; tcpd->num2_acks=num2_acks; tcpd->base_seq1=base_seq; + tcpd->base_seq2=base_ack; } else { tcpd->ual1=ual2; tcpd->ual2=ual1; @@ -1066,6 +1074,7 @@ ack_finished: tcpd->num1_acks=num2_acks; tcpd->num2_acks=num1_acks; tcpd->base_seq2=base_seq; + tcpd->base_seq1=base_ack; } |