tcpdump capturing tcp resets by host

Question

I am trying to figure out where my tcp resets on my webserver happen. I have the following capture:

tcpdump -fnni bond0:-nnvvS -w dump.pcap 'tcp[tcpflags] & (tcp-rst) !=0'

When I look at the pcap in wireshark shows me resets:

    Flags: 0x004 (RST)
    .... .... .1.. = Reset: Set
    .... .... ..0. = Syn: Not set
    .... .... ...0 = Fin: Not set

Window size value: 0
Calculated window size: 0
Window size scaling factor: -1 (unknown)
Checksum: 0x0f2f [validation disabled]
Good Checksum: False
Bad Checksum: False

but doesn't show me who reset the connection. I believe that there are switches in tcpdump that would allow me to see who reset the connection and possibly why. I have tried various switches with no luck.

Thanks in advance for your help.

Solution

Pay attention to the Src Port and Dst Port:

Transmission Control Protocol, Src Port: http (80), Dst Port: norton-lambert (2338), Seq: 1406431331, Len: 0
    Source port: http (80)
    Destination port: norton-lambert (2338)
    [Stream index: 3]
    Sequence number: 1406431331
    Header length: 20 bytes
    Flags: 0x004 (RST)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...0 .... = Acknowledgment: Not set
        .... .... 0... = Push: Not set
        .... .... .1.. = Reset: Set
            [Expert Info (Chat/Sequence): Connection reset (RST)]
                [Message: Connection reset (RST)]
                [Severity level: Chat]
                [Group: Sequence]
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set

Src Port: http (80) means that this RST packet was sent from server side.

If it come from the client side, then you should see the reason:

Transmission Control Protocol, Src Port: 57715 (57715), Dst Port: http (80), Seq: 3509013939, Len: 0
    Source port: 57715 (57715)
    Destination port: http (80)
    [Stream index: 32]
    Sequence number: 3509013939
    Acknowledgment Number: 0xd1274db3 [should be 0x00000000 because ACK flag is not set]
        [Expert Info (Warn/Protocol): Acknowledgment number: Broken TCP. The acknowledge field is nonzero while the ACK flag is no
t set]
            [Message: Acknowledgment number: Broken TCP. The acknowledge field is nonzero while the ACK flag is not set]
            [Severity level: Warn]
            [Group: Protocol]
    Header length: 20 bytes
    Flags: 0x004 (RST)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...0 .... = Acknowledgment: Not set
        .... .... 0... = Push: Not set
        .... .... .1.. = Reset: Set
            [Expert Info (Chat/Sequence): Connection reset (RST)]
                [Message: Connection reset (RST)]
                [Severity level: Chat]
                [Group: Sequence]
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set

Comments

[ott--]

The peer resets the connection. Can you show the last lines of the log? A connection is normally terminated by FIN, FIN+ACK and/or RST.

[rahrahruby]

I added additional information from the wireshark view of the packet.

[ott--]

No, I meant just the last lines of a connections, not the details for one line.

[bortzmeyer]

You ommitted the really important part of tcpdump's output, the source and destination IP addresses...

[Admin]

Did you figure out about the RST? Mark answer accepetd?