Bug 236219 - netmap bug pf set prio
Summary: netmap bug pf set prio
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 11.2-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
Depends on:
Reported: 2019-03-04 14:25 UTC by r.gabet
Modified: 2019-03-14 08:13 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description r.gabet 2019-03-04 14:25:53 UTC

I use "set priority", it's working fine, the priority value is reflected in the VLAN header.

According to the documentation :

"Set the priority of packets matching this rule. If both priorities are set here, packets with a TOS of "lowdelay" or TCP ACKs with no data payload will be assigned the latter. If the packets are transmitted on a VLAN interface, the queueing priority will be written as the priority code point in the 802.1Q VLAN header."

But if I use suricata in IPS mode with netmap, the priority vlan isn't set.

Comment 1 Vincenzo Maffione freebsd_committer 2019-03-06 12:03:26 UTC
  This is the documentation of what exactly?
Comment 2 r.gabet 2019-03-07 07:13:18 UTC
Sorry, I forgot to precise, it's "set prio" of packet filter.

Comment 3 Vincenzo Maffione freebsd_committer 2019-03-07 09:51:48 UTC
I see. The behaviour you are observing is expected, because netmap is a kernel bypass solution. This means that packets are transmitted from user-space to the NIC without going through the normal kernel stack datapath, including pf/ipfw and similar.
The reason for bypassing everything is efficiency (at least assuming that your IPS interface has native netmap support).
In other words it is not doable to get the behaviour that you are looking for.
Comment 4 r.gabet 2019-03-08 12:56:36 UTC
However, the packets still passe by packet filter, even with the IPS enabled. I can see them when I enable logging.
Comment 5 Vincenzo Maffione freebsd_committer 2019-03-08 14:08:49 UTC
Is suricata using netmap over a VLAN interface (rather than a physical interface)?
In that case you are going through the "emulated netmap adapter", which is a way to use netmap (at reduced performance, and with some functional limitation) over any Ethernet interface. In other words, VLAN interfaces do not (and cannot) have native netmap support (e.g. like ixl, ixgbe, em, vtnet, vmx, etc).
This may explain what you see, since in emulated mode you are still partially using the network stack.

Or maybe your suricata is configured to forward packets between the physical interface and its host rings (e.g. between "igb" and "igb+"), which means that packets actually pass through the FreeBSD network stack, and therefore through pf.

In any case netmap does not touch the packets in any way, and does not call into any firewall or similar packet processing element.
Comment 6 r.gabet 2019-03-11 06:58:09 UTC
Yes, Suricata is configured to forward packets between the physical interface and its host rings.
Comment 7 Vincenzo Maffione freebsd_committer 2019-03-11 08:44:36 UTC
If you are using a physical interface (e.g. em0 with em0+), where do VLANs come into the picture?
Comment 8 r.gabet 2019-03-14 07:14:36 UTC
Sorry for confusion, Suricata is configured to forward between em0_vlan70 and em0_vlan70+ in both direction.

I also tried to use directly physical interface but the vlan 70 isn't working.
Comment 9 Vincenzo Maffione freebsd_committer 2019-03-14 08:13:10 UTC
This is already an issue by itself. Netmap is not designed to run on VLAN interfaces. The application should always open the phisical interface and play with VLAN headers directly. Of course if suricata does not support this you would need to implement that.

Think of Netmap over VLAN interfaces as a thing that "kind of works" (at slow rate, however, because emulated mode is necessary), but that can show some quirks w.r.t. the kernel stack.