af-packet: respect vlan.use-for-tracking in eBPF bypass by ssam18 · Pull Request #15469 · OISF/suricata

ssam18 · 2026-05-28T14:18:01Z

Make sure these boxes are checked accordingly before submitting your Pull Request. Thank you.

Contribution style:

I have read the contributing guide lines at
https://docs.suricata.io/en/latest/devguide/contributing/contribution-process.html

Our Contribution agreements:

I have signed the Open Information Security Foundation contribution agreement at
https://suricata.io/about/contribution-agreement/ (note: this is only required once)

Changes (if applicable):

I have updated the User Guide (in doc/userguide/) to reflect the changes made
I have updated the JSON schema (in etc/schema.json) to reflect all logging changes
(including schema descriptions)
I have created a ticket at
https://redmine.openinfosecfoundation.org/projects/suricata/issues

Link to ticket: https://redmine.openinfosecfoundation.org/issues/8242

Supersedes #15458 (opened as a fresh PR per @catenacyber's request).

SV_BRANCH=OISF/suricata-verify#3113

Describe changes

AFPBypassCallback and AFPXDPBypassCallback in src/source-af-packet.c now AND p->vlan_id[N] with g_vlan_mask before writing it into the eBPF flow_table_v4 / flow_table_v6 map keys, so the bypass key reflects the active vlan.use-for-tracking configuration instead of always including the raw VLAN id. Without this, vlan.use-for-tracking: no is silently ignored on the bypass path: tracked flows write keys with the VLAN id present, but the matching ingress lookup writes with the VLAN id zeroed, so the bypass never matches and the flow is reprocessed each packet.

CI / SV coverage

This PR includes two commits from #15415, picked with @catenacyber's agreement, so SV coverage actually runs:

2e37d88 (catenacyber) ci: add new xdp build with live tests: adds the ubuntu-xdp job to .github/workflows/builds.yml that runs suricata-verify/run.py --live --debug-failed (no equivalent job exists on main today).
762d2d7 (catenacyber) test: new afpacket max-packets feature: adds the AFPACKET_TEST_REPLAY compile-time feature (all changes #ifdef-guarded; only the new ubuntu-xdp job sets -DAFPACKET_TEST_REPLAY, so other builds are byte-identical), used by the SV live test in suricata-verify#3113 to stop Suricata cleanly after the replay.

The matching SV PR suricata-verify#3113 that replays three VLAN-tagged UDP packets on the same 5-tuple through a dummy interface and asserts the bypass path engages with vlan.use-for-tracking: no.

AFPBypassCallback and AFPXDPBypassCallback populate the flow_table_v4 and flow_table_v6 eBPF maps using p->vlan_id[N] directly. When the matching xdp_filter.c program is built with VLAN_TRACKING=0 (i.e. vlan.use-for-tracking is false in suricata.yaml), the kernel side writes vlan0 and vlan1 as 0 on every map lookup, so userspace inserts that carry the real VLAN id never match and per-flow bypass counters stay at zero. Apply g_vlan_mask to each vlan_id assignment, matching the masking pattern already used by flow-hash.c. When vlan.use-for-tracking is true, g_vlan_mask is 0xffff and behaviour is unchanged. Original patch by John Graat on Redmine ticket 8242. Rebased to current main and dropped the now-removed vlan2 field. Ticket: 8242

for SV to run tests based on the presence of this feature

so as to run ebpf live tests

Ticket: 7674 Allows a compile-time option AFPACKET_TEST_REPLAY, that allows to set a configuration max-packets per afpacket interface, after which the PktAcqLoop stops. This allows suricata-verify tests to run with tcpreplay, and know when to stop

victorjulien · 2026-05-28T17:35:07Z

 #endif
-
+#ifdef AFPACKET_TEST_REPLAY
+    uint32_t max_packets;


Please add a comment here explaining what it is, and the meaning of the special meaning of the 0 value

This will be on me I guess

Adding this

victorjulien · 2026-05-28T17:35:39Z

            StatsCounterIncr(&ptv->tv->stats, ptv->capture_afp_poll_data);
            r = AFPReadFunc(ptv);
+#ifdef AFPACKET_TEST_REPLAY
+            if (ptv->max_packets > 0 && ptv->pkts >= ptv->max_packets) {


would expect a simple explanation here as well

also, this is comparing a uint64_t and uint32_t, should we cast max_packets to u64?

should we cast max_packets to u64?

Only when we want to have SV test with more than U32_MAX packets

victorjulien · 2026-05-28T17:37:47Z

      - run: tar xf prep/suricata-verify.tar.gz
      - run: ./autogen.sh
-      - run: CFLAGS="${DEFAULT_CFLAGS}" ./configure --enable-warnings --enable-unittests --enable-ebpf --enable-ebpf-build
+      - run: CFLAGS="${DEFAULT_CFLAGS} -DAFPACKET_TEST_REPLAY" ./configure --enable-warnings --enable-unittests --enable-ebpf --enable-ebpf-build


Generally we add configure options to define macros. Not sure how I feel about it here though. Opinions?

Some context :

The goal here is to run SV tests with tcpreplay
So, we need a way for Suricata to know that it should stop
This is a test feature

So, I think it is ok this way, but if you want a configure option, I can do it this way

@victorjulien

ptv->pkts is uint64_t and ptv->max_packets is uint32_t; cast the latter so the comparison is unsigned and same-width, addressing @victorjulien's review comment on OISF#15469.

Mirror the doc comment from the AFPThreadVars copy onto the config struct field, since they hold the same value (config -> per-thread copy at init).

ssam18 and others added 4 commits May 20, 2026 11:43

features: add EBPF as a feature

e0f4abe

for SV to run tests based on the presence of this feature

ci: add new xdp build with live tests

2e37d88

so as to run ebpf live tests

test: new afpacket max-packets feature

762d2d7

Ticket: 7674 Allows a compile-time option AFPACKET_TEST_REPLAY, that allows to set a configuration max-packets per afpacket interface, after which the PktAcqLoop stops. This allows suricata-verify tests to run with tcpreplay, and know when to stop

ssam18 requested review from jasonish and victorjulien as code owners May 28, 2026 14:18

ssam18 mentioned this pull request May 28, 2026

af-packet: respect vlan.use-for-tracking in eBPF bypass #15458

Closed

5 tasks

victorjulien requested changes May 28, 2026

View reviewed changes

ssam18 added 2 commits May 28, 2026 17:57

af-packet: widen max_packets comparison to uint64_t

55fbd3d

ptv->pkts is uint64_t and ptv->max_packets is uint32_t; cast the latter so the comparison is unsigned and same-width, addressing @victorjulien's review comment on OISF#15469.

af-packet: document max_packets in AFPIfaceConfig

84c86c2

Mirror the doc comment from the AFPThreadVars copy onto the config struct field, since they hold the same value (config -> per-thread copy at init).

catenacyber mentioned this pull request Jun 2, 2026

af-packet: mask vlan id in ebpf map keys - v1 #15502

Closed

5 tasks

catenacyber mentioned this pull request Jun 28, 2026

Xdp tunnel 7674 v18 #15746

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

af-packet: respect vlan.use-for-tracking in eBPF bypass#15469

af-packet: respect vlan.use-for-tracking in eBPF bypass#15469
ssam18 wants to merge 6 commits into
OISF:mainfrom
ssam18:fix/issue-8242-vlan-mask-ebpf-bypass-v3

ssam18 commented May 28, 2026 •

edited

Loading

Uh oh!

victorjulien May 28, 2026

Uh oh!

catenacyber May 28, 2026

Uh oh!

catenacyber Jun 28, 2026

Uh oh!

victorjulien May 28, 2026

Uh oh!

victorjulien May 28, 2026

Uh oh!

catenacyber Jun 28, 2026

Uh oh!

victorjulien May 28, 2026

Uh oh!

catenacyber May 28, 2026

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

ssam18 commented May 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Contribution style:

Our Contribution agreements:

Changes (if applicable):

Describe changes

CI / SV coverage

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

3 participants

ssam18 commented May 28, 2026 •

edited

Loading