# Possible NFQUEUE bug:  repeat-mark  omitted with  batchcount \> 1  in workers mode

**URL:** <https://forum.suricata.io/t/possible-nfqueue-bug-repeat-mark-omitted-with-batchcount-1-in-workers-mode/6478>\
**Category:** Developers\
**Tags:** ips, rules, suricata\
**Created:** [October 1, 2026, 9:54pm UTC](https://forum.suricata.io/t/possible-nfqueue-bug-repeat-mark-omitted-with-batchcount-1-in-workers-mode/6478 "2026-10-01T21:54:19Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![cvontela\_microsoft](https://yyz2.discourse-cdn.com/flex030/user_avatar/forum.suricata.io/cvontela_microsoft/32/3973_2.png) [@cvontela\_microsoft](https://forum.suricata.io/u/cvontela_microsoft)\
**Post date:** [October 1, 2026, 9:54pm UTC](https://forum.suricata.io/t/possible-nfqueue-bug-repeat-mark-omitted-with-batchcount-1-in-workers-mode/6478/1 "2026-10-01T21:54:19Z")

</div>

We reproduced an NFQUEUE packet loop with Suricata 8.0.7 when combining workers mode, repeat mode and verdict batching.

Suricata is started with:

suricata -c /etc/suricata/suricata.yaml  
-q 1000  
–runmode workers

Relevant configuration:

nfq:  
mode: repeat  
repeat-mark: 0x2000  
repeat-mask: 0x2000  
batchcount: 20  
fail-open: no

The relevant iptables chain is:

-A IDPS\_INSPECT -m mark --mark 0x4000/0x4000  
-j NFQUEUE --queue-num 500 --queue-bypass

-A IDPS\_INSPECT -m mark --mark 0x2000/0x2000  
-j RETURN

-A IDPS\_INSPECT  
-j NFQUEUE --queue-num 1000 --queue-bypass

The intended behavior is:

1. An uninspected packet enters queue 1000.
2. Suricata inspects it.
3. Suricata returns NF\_REPEAT with mark 0x2000 .
4. The repeated packet matches the 0x2000 rule and leaves the inspection chain.

With batchcount: 20 , ordinary packets repeatedly return to queue 1000 without matching the 0x2000 rule. The NFQUEUE packet sequence increased and TCP connections timed out.

Changing only this setting resolves the issue:

nfq:  
batchcount: 1

With --runmode workers and batchcount: 1 :

• The NFQUEUE loop stops.  
• Normal TCP/TLS connections complete successfully.  
• The expected repeat-mark behavior works.

Reviewing source-nfq.c , the individual-verdict path explicitly combines nfq\_config.mark with the packet mark for NFQ\_REPEAT . The verdict-cache path appears to consider only mark\_modified . For an ordinary packet, mark\_modified is false, so the cache appears to use nfq\_set\_verdict\_batch() rather than a mark-aware batch verdict containing the configured repeat mark.

Is batchcount \> 1 expected to be supported with nfq.mode: repeat and nfq.repeat-mark ? If so, should the batched path apply the effective repeat mark through nfq\_set\_verdict\_batch2() ?

Environment

• Suricata 8.0.7  
• NFQUEUE workers run mode  
• Linux iptables  
• libnetfilter\_queue batch-verdict support enabled  
• Reproduced with normal TCP/TLS traffic; no alert or drop rule is required  
• batchcount: 20 reproduces consistently  
• batchcount: 1 consistently resolves the issue