Asankha C. Perera wrote:
On 05/26/2011 09:50 PM, André Warnier wrote:
Putting your answer together with the one from Chuck :
I understand that if the tcpdump program runs on the same host as the
one which is sending the packets, it may not be able to correctly see
the TCP checksum, since it captures the packet before it goes out on
the network, and it is the NIC which calculates and inserts the TCP
checksum just before the packet is sent over the network.
Right ?
But is this the case here ?
Where is/was the tcpdump program run, which captured these packets, as
compared to the "client" and "server" systems ?
I am quite certain this was from the ESB node which was the "client" to
tomcat ..
In that case it looks indeed like a false alarm.
In the second link which you provided, I note this :
quote
As this may be confusing and will prevent Wireshark from reassemble TCP segments it's a
good idea to switch checksum verification off in these cases.
To disable checking of the TCP checksum validity, go to the TCP preferences and untick the
box for checksum verification
unquote
Doing this may thus allow wireshark to better reassemble the packets and make the display
somewhat clearer. Maybe avoiding these in the process :
391894 37.115837 10.77.69.8 10.101.29.42 HTTP 9062 8080
Continuation or non-HTTP traffic[Packet size limited during capture]
and see more clearly what is being POST-ed.
(Maybe it contains a clue about the reset ?)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
