Project

General

Profile

Actions

Support #2720

closed

Suricata + Netmap + FreeBSD -- source of bad pkt netmap errors?

Added by booble tins over 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Low
Assignee:
Affected Versions:
Label:

Description

Apologies in advance for my limited understanding of C, memory management, and network programming.

I'm trying to nail down the source of repeated "bad pkt" errors that netmap throws when used by Suricata on FreeBSD. I have resolved this issue in my case by setting appropriate system tuneables. However, the issue persists for others and I cannot explain that given the data/examples/settings they provide.

netmap.c : https://github.com/luigirizzo/netmap/blob/1c4a65a8a7a1e0ab0eb824abb239615d7464990c/sys/dev/netmap/netmap.c

In these situations netmap_grab_packets() is regularly throwing "bad pkt" with slot->len > 2048 (which is the default dev.netmap.buf_size). The part I don't understand is these examples all have default MTUs of 1500. It would make sense if they had jumbo packets with MTUs of 9000, but they never do. As I read the netmap code, this means that the slot->len should never be above something like 1518 -- certainly lower than 2048. I can't explain how they get slot->len numbers like 2200 or sometimes in the 4000s with an MTU of 1500 (on my machines I can lower the default dev.netmap.buf_size to 1920 without running into these errors).

So maybe this seems like a netmap issue. But when I look into that I see that netmap_grab_packets() is called by netmap_txsync_to_host() which is called by a "user process context" (which I read to be the application using netmap: "Suricata" in this case?).

If I'm following (unlikely), Suricata is calling netmap_txsync_to_host() and providing the ring with the slot that is oversized. Netmap then chokes on a packet that is too large for its buf_size.

I hope the question makes sense. I suppose this could be a driver issue or a FreeBSD issue - maybe the packet is oversized when Suricata gets it -- I can't tell, as I have trouble tracing the flow of data between OS/Driver/Suricata/Netmap.

To head off a few questions:
-users who get oversized packets while running Suricata+netmap are using the same driver and nic chipsets as me
-checksum offloading and other required settings have been compared and are all "correct"

If you're confident that the oversized packets are coming from elsewhere, I'll try to take the question there. Netmap devs say this isn't their issue (increase dev.netmap.buf_size) -- That works, but that doesn't explain why the MTU and packet sizes aren't respected. A user moved dev.netmap.buf_size to 4096 only to have bad pkt errors with Suricata running with slot->len > 4200.

Actions

Also available in: Atom PDF