You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up to #1995. When loading a pcap with certain link types, libpcap will return an error that looks like this:
fatal error in /Users/tim/Desktop/projects/zeek/scripts/base/frameworks/packet-filter/./main.zeek, line 292: cannot compile BPF filter "ip or not ip": pcap_compile(ip or not ip): IEEE 802.15.4 link-layer type filtering not implemented
This isn't necessarily an error though, it's just that libpcap only implements link-layer filtering for certain link types. See the gen_linktype() method in libpcap at https://github.com/the-tcpdump-group/libpcap/blob/64ed5bbd93520ff63ac735d07ef3514ca0dcdd68/gencode.c#L3190 for a list of what is supported and what isn't. Libpcap doesn't return any sort of error codes or anything about why a filter failed to compile, only an error string. Thankfully that string seems to be fairly stable as of the last 20 years or so (I looked), so we can use the presence of "filtering not implemented" in the error string.
Unfortunately, that's the easy part. We still need to propagate that "failed but not failed" state upwards through the call stack to the original call to Pcap::precompile_pcap_filter in PacketFilter::install in script-land so it can exit cleanly instead of just assuming that every return value of false means a hard failure. On top of that, we need to investigate whether this is something that happens on live traffic as well.
The text was updated successfully, but these errors were encountered:
For the second part of this, I'm going to opt not to break the existing API for PktSrc::PrecompileBPFFilter. Instead I'm planning to add a method that returns either an enum value or a string for the reason for the failure (I haven't decided which yet). I'm leaning towards a string since that would let third-party packet source plugins implement their own error strings. It'll probably actually need to be a pair<bool,string> that indicates whether the error is catastrophic and the reason. Callers of PrecompileBPFFilter and friends can check for the bool result, and then call that new method if the result is false and handle it appropriately.
The above will require similar changes in BPF_Program but all of that code is in the zeek::iosource::detail namespace so it's not beholden to deprecation rules.
This is a follow-up to #1995. When loading a pcap with certain link types, libpcap will return an error that looks like this:
This isn't necessarily an error though, it's just that libpcap only implements link-layer filtering for certain link types. See the
gen_linktype()
method in libpcap at https://github.com/the-tcpdump-group/libpcap/blob/64ed5bbd93520ff63ac735d07ef3514ca0dcdd68/gencode.c#L3190 for a list of what is supported and what isn't. Libpcap doesn't return any sort of error codes or anything about why a filter failed to compile, only an error string. Thankfully that string seems to be fairly stable as of the last 20 years or so (I looked), so we can use the presence of "filtering not implemented" in the error string.Unfortunately, that's the easy part. We still need to propagate that "failed but not failed" state upwards through the call stack to the original call to
Pcap::precompile_pcap_filter
inPacketFilter::install
in script-land so it can exit cleanly instead of just assuming that every return value offalse
means a hard failure. On top of that, we need to investigate whether this is something that happens on live traffic as well.The text was updated successfully, but these errors were encountered: