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 symptom is originally described in brimdata/zui#790 (comment). Alas, it's only with large test data that I've been able to reproduce this, but at least it's all publicly available.
With an out-of-the-box compile of Zeek v3.1.3 on my Mac, when I ask Zeek to process this 25 GB pcapng, it exits almost immediately with an error code of 0 (indicating success) but produces almost no data.
$ /usr/local/zeek-3.1.3/bin/zeek -C -r ../brim-790.pcapng local
WARNING: No Site::local_nets have been defined. It's usually a good idea to define your local networks.
$ echo $?
0
$ ls -l
total 80
-rw-r--r-- 1 phil staff 30422 May 18 11:12 loaded_scripts.log
-rw-r--r-- 1 phil staff 254 May 18 11:12 packet_filter.log
-rw-r--r-- 1 phil staff 694 May 18 11:12 stats.log
As described at brimdata/zui#790, it seems likely the pcapng is corrupt (probably the fault of mergecap), but it's unfortunate that Zeek didn't surface any kind of error about the presumed corruption. For instance, tcpdump does complain:
$ tcpdump -r ../brim-790.pcapng
reading from PCAP-NG file ../brim-790.pcapng
tcpdump: pcap_loop: invalid packet capture length 260, bigger than snaplen of 96
$ tcpdump --version
tcpdump version tcpdump version 4.9.3 -- Apple version 90.100.1
libpcap version 1.9.1
LibreSSL 2.8.3
The text was updated successfully, but these errors were encountered:
Switches from pcap_next() to pcap_next_ex() to better handle all error
conditions. This allows, for example, to have a non-zero exit code for
a Zeek process that fails to fully process all packets in a pcap file.
Thanks @jsiwek! I've verified with Zeek master compiled as of commit 6cec268 and the original repro steps that this problem has been addressed.
$ /usr/local/zeek-master/bin/zeek -C -r brim-790.pcapng local
WARNING: No Site::local_nets have been defined. It's usually a good idea to define your local networks.
fatal error: failed to read a packet from brim-790.pcapng: an interface has a snapshot length 4096 different from the type of the first interface
…-changes
* origin/master: (33 commits)
Fix location where CI places build.tgz
Update submodule(s)
Disable some deprecation diagnostics for GCC
Compare pcap_next_ex() result to PCAP_ERROR/PCAP_ERROR_BREAK
Optimize Connection::RemovalEvent() for bare-mode usage
Rename BroType to Type
Update NEWS
Review cleanup
Move Type types to zeek namespace
Review cleanup
Restrict Cirrus CI to only zeek repo's branches
GH-977: Improve pcap error handling
Remove not-useful code in iosource::Manager::OpenPktSrc
GH-999: Stop formatting DHCP Client ID Hardware Type 0 as MAC
Remove inline from some static KeyedHash members
Improve Func.h inclusion
Fix NVT analyzer memory leak from multiple telnet authn name options
Rename aux/ to auxil/
Move Flare/Pipe from the bro namespace to zeek::detail
Move Attr to the zeek::detail namespace
...
This symptom is originally described in brimdata/zui#790 (comment). Alas, it's only with large test data that I've been able to reproduce this, but at least it's all publicly available.
Download/uncompress these three files:
http://mawi.wide.ad.jp/mawi/samplepoint-F/2015/201508051400.dump.gz
https://download.netresec.com/pcap/maccdc-2011/maccdc2011_00010_20110312194033.pcap.gz
https://download.netresec.com/pcap/maccdc-2011/maccdc2011_00013_20110312202724.pcap.gz
Use
mergecap
to combine them into a single pcapng file:With an out-of-the-box compile of Zeek v3.1.3 on my Mac, when I ask Zeek to process this 25 GB pcapng, it exits almost immediately with an error code of 0 (indicating success) but produces almost no data.
As described at brimdata/zui#790, it seems likely the pcapng is corrupt (probably the fault of
mergecap
), but it's unfortunate that Zeek didn't surface any kind of error about the presumed corruption. For instance,tcpdump
does complain:The text was updated successfully, but these errors were encountered: