The documentation states:
// It should return true if the connection should be removed from the pool
// It can return false if it want to see subsequent packets with Accept(), e.g. to
// see FIN-ACK, for deeper state-machine analysis.
Somewhat ambiguous comment in the reassemblydump tells the following:
|
func (t *tcpStream) ReassemblyComplete(ac reassembly.AssemblerContext) bool { |
|
Debug("%s: Connection closed\n", t.ident) |
|
if t.isHTTP { |
|
close(t.client.bytes) |
|
close(t.server.bytes) |
|
} |
|
// do not remove the connection to allow last ACK |
|
return false |
What it actually means in practice, is that when connection is closed with e.g. [FIN,ACK], [ACK], [FIN,ACK], [ACK], ReassemblyComplete is called on the second [FIN,ACK] packet. If ReassemblyComplete returns true, connection will be removed from the pool. The last [ACK] will actually recreate connection again, which will become stuck in the pool forever (or until it will be flushed with FlushWithOptions).
In other words, it's kinda lose-lose scenario. No matter what you'll return from ReassemblyComplete, you'll either have original connection stuck in the pool forever, or final ACK recreating connection which will be stuck forever anyway.
I noticed it when analysing some dumps. Running StreamPool.Dump at some point gave me some connections with noticeably different activity times:
[10.66.85.2->10.65.85.1 4242->52538] c2s: created:2015-12-18 19:36:34.654147 +0000 UTC, last:2015-12-18 19:36:34.654147 +0000 UTC, s2c: created:2015-12-18 19:36:34.654147 +0000 UTC, last:2015-12-18 19:36:34.654147 +0000 UTC
[10.65.85.1->10.66.85.2 40927->4242] c2s: created:2015-12-18 19:50:22.275428 +0000 UTC, last:2015-12-18 19:50:22.275428 +0000 UTC, s2c: created:2015-12-18 19:50:22.275428 +0000 UTC, last:2015-12-18 19:50:22.275428 +0000 UTC
Notice the first connection has the same activity time in all fields. It's actually the timestamp of that last ACK packet.
The documentation states:
Somewhat ambiguous comment in the reassemblydump tells the following:
gopacket/examples/reassemblydump/main.go
Lines 451 to 458 in b40365f
What it actually means in practice, is that when connection is closed with e.g.
[FIN,ACK],[ACK],[FIN,ACK],[ACK],ReassemblyCompleteis called on the second[FIN,ACK]packet. IfReassemblyCompletereturns true, connection will be removed from the pool. The last[ACK]will actually recreate connection again, which will become stuck in the pool forever (or until it will be flushed withFlushWithOptions).In other words, it's kinda lose-lose scenario. No matter what you'll return from
ReassemblyComplete, you'll either have original connection stuck in the pool forever, or final ACK recreating connection which will be stuck forever anyway.I noticed it when analysing some dumps. Running
StreamPool.Dumpat some point gave me some connections with noticeably different activity times:Notice the first connection has the same activity time in all fields. It's actually the timestamp of that last ACK packet.