"brimcapd" server

[philrz]

At the moment Brimcap only allows for populating and querying a local "Brimcap root". This means that if a Brim app is connected to a remote lake and accesses a pool that was created by loading a pcap via Brimcap at that remote side, when they click the Packets button, their local Brimcap root will still be queried and the flow will not be found. If the user is savvy enough to run brimcap index locally against the same pcap to populate their personal Brimcap root, that would make the Packets button work as expected. But this is probably asking too much of users.

When contemplating this feature gap, we recognized there's room for something like a "brimcapd server" such that the local Brimcap could do a remote "search" by connecting to the remote brimcapd, which could then extract the relevant flow and return it over the network to be displayed locally in Wireshark.

[philrz]

Note that issue is linked to from the Remote Workspaces (v0.25.0+) article in the Brim wiki. If/when this gets addressed, the article should be updated.

[pasdesignal]

The packets/wireshark feature of brimcap is certainly a very powerful feature that provides a lot of the value in my opinion. If this was possible using remote data lakes (which is also a great feature for implementing a continuous stream of logs) it would be awesome.

[duffy-ocraven]

https://www.qacafe.com/analysis-tools/cloudshark/tech-integrations/pcapdaemon is an example of an OEM partnership, where Cloudshark/qacafe.com had done the heavy-lifting for this problem domain. Maybe the 85% solution is to Partner/OEM program with them?