# retransmission detection # # The rules below match on retransmissions detected in various stages of the # stream engine. They are all “noalert” rules that increment the counter # tcp.retransmission.count. The last rule sid:2210054 matches if the counter # reaches 10. Increase this number if the rule is too noisy.
alert tcp any any → any any (msg:“SURICATA STREAM excessive retransmissions”; flowbits:isnotset,tcp.retransmission.alerted; flowint:tcp.retransmission.count,>=,10; flowbits:set,tcp.retransmission.alerted; classtype:protocol-command-decode; sid:2210054; rev:1;)
Maybe try to increase retransmission count from 10 to higher value.
A long-standing bug with broken cable modems has been fixed: Some providers have cable modems which return an unusually small MTU of only 576 bytes which will cause that IPFire will fragment every packet larger than this before it can be sent out on the RED interface. This can now properly changed in the setup tool and IPFire will accept any custom value. This used to break video conferences over UDP which could not re-assemble the fragmented video stream and which did not automatically fall back to TCP (#12563).
Depending on your isp, this might require investigation too.
given that descriptions, I don’t really see a benefit in this rule. Retransmissions happen all the time, and while more than 10 of them should not occur in robustly connected setups, they may well happen if a connection is unstable, or has a lot of latency (or some packet loss) involved. Cellular networks match that description.
Are things fine again if this IPS rule is disabled? Or are we dealing with a more general problem here?