Provide guidance on macOS/Linux when no app is tied to opening of pcaps

[philrz]

A community user recently reported a problem with Wireshark not opening when the Packets button was clicked in Brim. This inspired me to revisit the user experience when they're running Brim on an OS that lacks any installed/configured app tied to the opening of pcaps (e.g. Wireshark not installed). Repros are with GA Brim tagged v0.22.0.

On Windows (repro was on Server 2019) we seem pretty well covered. As shown in the attached video, when the Packets button is hit, a familiar "Windows can't open this type of file (.pcap)" message pops up.

Windows.mov

On macOS (repro was on Big Sur) and Linux (repro was on Debian 10) it's not great. As shown in the videos below, the user sees the "Download Complete" message, but no app appears (expected) and no message is shown to explain why (that's bad!) I've kept the Dev Tools console window open during these repros to show that there doesn't seem to be an underlying message tied to this.

macOS.mov

Linux.Debian.10.mov

If we can recognize this occurrence and provide guidance, that would be a great improvement.

After the community user's experience, they also offered the opinion:

I think it might be helpful if the "download complete" message showed the directory that the files get saved into. I found them in my /tmp directory by accident.

Since these are supposed to be just temporary flow extractions, I'm not sure if this is something we'd want to add since it might give the user the impression that they're responsible for hunting down the files in that location, but for the "happy path" they should simply open in the appropriate app without issue. But this is good feedback, so I'm including it here for consideration when revisiting this UX.

[philrz]

Note to self: If/when we make improvements here, I should be able to revise the wiki article updated via #1380.

[philrz]

This was recently reviewed with the UX team. We suspect the "open" would return a non-zero when the app fails to launch, and so we could catch this.

@jameskerr: Also noted that there's currently a few different places in Brim where things are "downloaded" in some way (this pcap flow extraction for opening in Wireshark, ZNG/CSV/NDJSON export, etc.), and he's had a thought for some time of creating a unifying way to handle all these. Perhaps we can create an Epic when this topic becomes the priority.

[alp1n3-eth]

Hi,
I'm going through the same problem on an M1 Mac. Did you figure out a solution to it? I have WireShark in my applications folder along with Brim, but hitting the "open in Wireshark" button does not work. The button works a-okay on my Windows desktop though. I have videos showing the clicking of the button, and the console not outputting any error messages as well if needed.

[philrz]

@Ibranum: A couple questions to help narrow it down.

1. Which Brim version are you running? The current version is shown when you select Brim > About Brim from the pull-down menu.
2. If you double-click a .pcap file in the macOS Finder outside of Brim, does it open in Wireshark?
3. If that checks out, just to rule out pcap-specific problems, could you try with a test pcap such as https://archive.wrccdc.org/pcaps/2018/wrccdc.2018-03-23.010014000000000.pcap.gz and confirm you can repro the problem with that as well? gunzip it after downloading, drag into the app, highlight the conn record that shows up on the first screen of results and see if the Packets button works for that.

[alp1n3-eth]

@philrz Here ya go! Thanks for helping!

1. 0.29.0
2. Yes
3. The Packets button does work here! Which prompted me to do some digging.

It turns out, I didn't realize that Brim wasn't storing the PCAPs and their information in its own directory but just the data lake itself that it had interpreted (sorry I'm VERY new to Brim). So when I moved the PCAP in its own directory to another one, Brim still had the old path to where the PCAP was and wasn't able to open it. Reloading the PCAP into Brim and ensuring it stays in its own location (AKA me not moving it haha) fixed this issue for me. Sorry for the trouble!

[philrz]

@Ibranum: Glad to hear you were able to figure out what was going on. Indeed, my next line of inquiry would have been to start to piece together the brimcap command lines the app would have been constructing to extract the flow for hand-off to Wireshark. If you've not already looked at it, you might find the materials at https://github.com/brimdata/brimcap and the Brimcap wiki of interest.

In any case, it's good that you were able to share your experience, as it points to another motivation to improve the error handling/messaging here.

[philrz]

Update: As of GA Brim tagged v0.31.0, I've confirmed the symptom as originally described still exists in macOS and Linux.

[philrz]

I'm pleased to report that since the changes merged from #2992, this problem has been addressed on macOS. As shown in the attached video, now when the Download Packets button is clicked and there's no app like Wireshark tied to the opening of pcap files, a system message is popped up. This is reminiscent of what we showed above for Windows,.

Verify-macOS.mp4

However, even at the tip of main (commit 7ba4321 at the moment) the behavior on Linux is still as previously described, so I'll continue to hold this issue open.

[philrz]

Verified in Zui Insiders 1.8.1-insiders.4, which is based on Zui commit 6a90407.

The videos below show where things now stand on each OS when Wireshark is not installed and the Packets button is clicked.

Linux

Linux is where the help was most needed, since the OS previously did not pop up any kind of error. Here we now have the benefit of the app's own error message "Could not open extracted pcap. Is Wirshark installed?"

Verify-Linux.mp4

macOS

As noted above, on current macOS (Sonoma 14.5 at the moment, specifically), the OS now pops up an error. We now have the benefit of that and the app's own error.

Verify-macOS.mp4

Windows

As noted above, on Windows we've always had the benefit of an OS error pop-up, and that is still true today. For some reason the Electron method we use to attempt the open does not seem to be acting as if it failed in this case, so the presentation of the app's own error is not happening here. However, since there's at least some error visible to the user and it's pretty clear what's going on, we're not going to invest effort right now digging into that.

Verify-Windows.mp4

---

Regarding two other points made earlier in this issue:

1. Since this issue has been fixed, the caution in the Brimcap Troubleshooting article about "silent" failure on macOS and Linux is no longer necessary. Update Troubleshooting article to drop reference to fixed issue zui#1379 brimcap#350 proposes dropping that text from the article.

2. In the time since the user made the point above about providing transparency about the folder to which pcap slices are being saved, we now have a Setting in the app to change this location, and this is all referenced in a Packet Captures article on the Zui docs site that includes a video, so hopefully this provides adequate coverage of the topic.