[bugzilla-daemon@xxxxxxxxxxxxx]

Jim Young changed bug 11481

What	Removed	Added
Status	UNCONFIRMED	RESOLVED
CC		jyoung@gsu.edu
Resolution	---	NOTABUG

Comment # 2 on bug 11481 from Jim Young

I see no issue with TCP reassembly here.

But this is an actual issue with the second TCP session.

Apply a display filter of tcp.stream eq 1 to exclude the packets from the from
the 1st TCP session.   You should see "[TCP Retransmission]" messages in the
Info column of the packet list.  These imply that there is an issue.

If you examine the TCP sequence numbers you can see the same data is
retransmitted several times.

After the initial 3-packet handshake there seems to be a problem with packets
reaching the client in a timely manner.

The client sends its Hello in frame 31.

The server sends its Hello in frame 32 and within the same frame acknowledges
that it has seen the client's frame 31 data (ACK=518).

The server then follows up with two more TCP segments (frames 33 and 34) that
ultimately are reassembled as the certificate reported in frame 34.

But at frame 35 the client retransmits the data it initially sent in frame 32
(the client hello).

At frame 36 the server retransmits the data it sent in frame 32 (the server
hello) again acknowledging that it received the client data sent in frame 31
(which was retransmitted for the 1st time in frame 35).

At frame 37, for the third time the client retransmits the data from frame 31
(the client hello).

1.69 seconds later at frame 38 the client retransmits the client Hello a 4th
time.

At frame 39 the client initiates closing this connection with a TCP FIN.  This
FIN is sent with an ACK number of 1 which indicates the client never saw any of
the server's data.

At frame 40 the server again retransmitted its first data (frame 32) to the
client.

At frame 41 the server sends a naked ACK and appears to acknowledge the FIN
because the ACK number is now 519.

3.86 seconds later the server again retransmits the data first sent in frame
32.

6.17 seconds later the server aborts the TCP session with the TCP RST.

Without any more info to go on (and not knowing where in the network this
packet was captured) I'm guessing there is some sort of stateful network device
(firewall, load balancer, etc) at play here perhaps with the possibility of
asymmetric network paths.

>From the clues in this one sample it would appear the server's packets are not
reaching the client.  I would try to capture a trace closer to the client to
set if some intermediate network component is consuming the packets.  Given
that the MAC address associated with the client's IP address is a Cisco device
I'm guessing that this trace was taken from a span port closer to the server.

I'm closing this ticket as I see no real issue with Wireshark's reassembly or
analysis.

---

      You are receiving this mail because:

• You are watching all bug changes.