Problem with TCP reset
I'm having trouble with TCP resets. A client will not connect to the host, across the internet, on port 7651. A packet cap on the client side shows source IP, destination IP, destination port, TTL (249) and RST.
What happens to the TCP handshake before the TCP RST?
Nothing! I see no ACK (for port 7651) which suggests the packet isn't making it to the destination before being reset.
2022-05-23 20:57:24 72.43.190.171 20.157.17.108 7653 OpenWire 65 127 KeepAliveInfo 2022-05-23 20:57:24 20.157.17.108 72.43.190.171 54828 OpenWire 65 116 KeepAliveInfo 2022-05-23 20:57:24 72.43.190.171 20.157.17.108 7653 OpenWire 246 127 ActiveMQStreamMessage 2022-05-23 20:57:24 72.43.190.171 20.157.17.108 7653 OpenWire 246 127 ActiveMQStreamMessage 2022-05-23 20:57:24 72.43.190.171 20.157.17.108 7653 TCP 54 127 54828 → 7653 [ACK] Seq=12 Ack=12 Win=256 Len=0 2022-05-23 20:57:24 20.157.17.108 72.43.190.171 54828 TCP 60 116 7653 → 54828 [ACK] Seq=12 Ack=12 Win=2044 Len=0 2022-05-23 20:57:24 20.157 ...(more)
Is it possible to capture packets on the wire? The output looks filtered.
This part of the trace matches your comment. TCP RESET for a session that is not in the trace.
2022-05-23 20:57:31 72.43.190.171 20.157.17.108 7651 TCP 54 249 54837 → 7651 [RST] Seq=1 Win=0 Len=0
2022-05-23 20:57:31 20.157.17.108 72.43.190.171 54837 TCP 60 117 7651 → 54837 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
I could be reading it wrong, but the traces for connections 7653+52809 and 7653+52810 are incomplete. The SEQ=1 from 20.157.17.108 with the LEN=0. The next set of packets are from 73.42.190.17 with ACK=12. I expected ACK=1 because the previous packets previous length was 0.
2022-05-23 20:57:24 20.157.17.108 72 ...(more)
unfortunately, as a newbie to this forum, I'm not able to attach a pcap and the dialog box will accept a limited number of characters. May I email a pcap?