 | 1 | initial version |
Hi Eric,
Packet #2262 is a [FIN,ACK] but shouldn't there be a [FIN] from the other side first?
Either side may close the connection by sending a FIN/ACK. This tells the other side that it won't send any more data.
Packet #2265 shows the same but the other way around
This is where the other side sends it's own FIN/ACK to indicate that it too will not send any more data. This means the connection is (almost) closed.
I can't place those random [ACK]'s at #2264 and #2267.
Both FIN/ACK packets need to be acknowledged, as both sides need to know their FIN/ACK was correctly received. This is accomplished by adding a "phantom" byte to the FIN/ACK packets. So even that there is no data in the FIN/ACK packets, it gets treated as if there was 1 byte of data. That's why you see the ACK's in frame #2264 and #2267
The only thing weird in this case is that 172.24.9.13 does not wait for the ACK to be received, but sends a RST straight after the FIN/ACK. This means the session will be removed from the TCP session table immediately (both on the endpoints as well as session based devices in the path between them). My bet is that the ACK in frame #2267 is now seen as a new session by the firewall, because it already removed the session from its sessiontable when it received the RST of frame #2266.
What kind of OS and Application is running on 172.24.9.13?