Skip to content

"Error: write EPIPE" or "Error: write EPIPE" on attempted pcap import #2926

@philrz

Description

@philrz

tl;dr

An attempt to import a pcap containing 802.11 traffic resulted in a JavaScript error pop-up. I suspect the root cause is a Zeek failure that bubbles up through Brimcap. It would seem ideal if we could catch and surface that error instead.

Details

Repro is with Zui commit 29860a0.

This issue was reported in a recent community Slack thread. In the user's own words:

Hi everyone, new here. Im trying to use zui to view some a pcap file for a cyber security challenge. Installed zui and then tried to import the pcap file but i get this error. same error on my windows 10 and my linux vm. Can anyone help me solve this issue?
image

The user shared their pcap VanSpy.pcapng.zip which I used to reproduce the problem with Zui 29860a0 on macOS as shown in the attached video. In my repro it happened to show Error: write EPIPE as the exception instead.

Repro.mp4

As it turns out, if I dismiss the pop-up I can see a handful of Zeek events were generated based on the pcap. However, since the user was clearly expecting to see more, the pop-up gives the impression that the limited data was possibly due to a bug.

After seeing this, I opened the pcap file in Wireshark and could see the likely problem: All the traffic is 802.11. We've confronted this before and a prior issue asking about 802.11 (#570) was closed a long time ago when the team concluded that there's really not much that can be done here since Zeek and Suricata seem to expect IP traffic. In the time since I can see some 802.11 references in the Zeek repo so maybe there's potential for something there, but we're currently stuck with the older Zeek/Suricata artifacts we've got.

After seeing this, I dropped to the shell and sniffed the brimcap command line out of ps and tried to run it by hand. Here's what I saw:

$ export BRIM_SURICATA_USER_DIR="$(pwd)"

$ cat VanSpy.pcapng | /Applications/Zui.app/Contents/Resources/app.asar.unpacked/zdeps/brimcap analyze -json -
{_path:"weird",ts:2023-11-25T14:50:28.326413Z,uid:null(string),id:{orig_h:null(ip),orig_p:null(port=uint16),resp_h:null(ip),resp_p:null(port)},name:"unknown_packet_type",addl:null(string),notice:false,peer:"zeek"}
{_path:"weird",ts:2023-11-25T14:50:36.923448Z,uid:null(string),id:{orig_h:null(ip),orig_p:null(port=uint16),resp_h:null(ip),resp_p:null(port)},name:"truncated_link_header",addl:null(string),notice:false,peer:"zeek"}
{_path:"weird",ts:2023-11-25T14:50:44.339188Z,uid:null(string),id:{orig_h:null(ip),orig_p:null(port=uint16),resp_h:null(ip),resp_p:null(port)},name:"non_ip_packet_in_ieee802_11",addl:null(string),notice:false,peer:"zeek"}
{_path:"stats",ts:2023-11-25T14:50:28.326413Z,peer:"zeek",mem:65(uint64),pkts_proc:1(uint64),bytes_recv:122(uint64),pkts_dropped:null(uint64),pkts_link:null(uint64),pkt_lag:null(duration),events_proc:423(uint64),events_queued:12(uint64),active_tcp_conns:0(uint64),active_udp_conns:0(uint64),active_icmp_conns:0(uint64),tcp_conns:0(uint64),udp_conns:0(uint64),icmp_conns:0(uint64),timers:39(uint64),active_timers:35(uint64),files:0(uint64),active_files:0(uint64),dns_requests:0(uint64),active_dns_requests:0(uint64),reassem_tcp_size:0(uint64),reassem_file_size:0(uint64),reassem_frag_size:0(uint64),reassem_unknown_size:0(uint64)}
{"type":"status","ts":{"sec":1702005480,"ns":385277000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005481,"ns":385356000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005482,"ns":385343000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005483,"ns":385330000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005484,"ns":385383000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005485,"ns":385368000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005486,"ns":385449000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005487,"ns":385443000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005488,"ns":385469000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005489,"ns":385463000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005490,"ns":386441000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005491,"ns":385530000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"status","ts":{"sec":1702005492,"ns":385516000},"pcap_read_size":65536,"pcap_total_size":65536,"values_written":4}
{"type":"error","error":"zeekrunner exited with code 1\nstdout:\nWARNING: No Site::local_nets have been defined.  It's usually a good idea to define your local networks.\nstderr:\n1700923856.942332 fatal error in \u003ccommand line\u003e, line 3: failed to read a packet from -: truncated pcapng dump file; tried to read 1596 bytes, only got 656\n"}

$ echo $?
1

So indeed, it looks like brimcap effectively failed because Zeek failed. However, is there any hope of catching the failure and surfacing the error in that last line instead of the JavaScript error that pops up now? If we could present that error text along with links to https://zui.brimdata.io/docs/support/Troubleshooting and https://github.com/brimdata/brimcap/wiki/Troubleshooting it would give the user a bit more to go on, e.g., I could make an entry in one of the Troubleshooting guides specifically acknowledging that 802.11 is not going to work.

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions