Dear Janak,
thank you for detailed report with pointers to the pf(4) code.
I've read your report and understand the source node connection counter
underflow issue (sn->conn underflow).
On Thu, Aug 06, 2026 at 11:31:34AM +0200, Janak Trivedi wrote:
</snip>
>
> Option 1 ??? Minimal fix (add zero check):
>
> /* CURRENT (buggy): */
> if (st->src.tcp_est)
> --sni->sn->conn;
>
> /* FIXED (safe): */
> if (st->src.tcp_est && sni->sn->conn > 0)
> --sni->sn->conn;
>
> Pros: Simple one-line change
> Prevents underflow completely
> Minimal risk of regression
> Cons: conn may slightly overcount during high-rate
> FIN_WAIT accumulation (benign)
I suspect the problem might be coming from non-atomic
manipulation of sn->conn counter.
The thing is the counter gets incremented on SYN_SENT -> ESTABLISHED
state transition. For that kind of transition the state exists already.
that means pf(4) runs with reader lock on state and source node table.
pf(4) might be simultaneously handling two packets which belong to two
different states but share the same source node entry. There are like two
threads doing sn->conn++; on the same `sn` instance. and just one counter
bump is observed.
I will try to reproduce the issue and verify my suspicion. Give me just
two or three days to come back here.
BTW: what hardware your router is using? is it amd64? or something else?
thanks and
regards
sashan
