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.

https://user-images.githubusercontent.com/5934157/105641843-0252e300-5e3b-11eb-86c6-59884300384b.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.

https://user-images.githubusercontent.com/5934157/105641898-4c3bc900-5e3b-11eb-83ac-d1e449dfad6a.mov

https://user-images.githubusercontent.com/5934157/105641903-5067e680-5e3b-11eb-8366-4bc22790b0ea.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 https://github.com/brimsec/brim/pull/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.

[Ibranum]

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.

[Ibranum]

@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.