Re: [Zeek-Dev] Zeek and the myricom package plugin

2019-07-15 Thread Jan Grashöfer
So https://github.com/J-Gras/bro-af_packet-plugin/issues/11 isn't an issue anymore due to backwards compatible symlinks? On 13/07/2019 03:22, Michał Purzyński wrote: > We just migrated to master with the name change and the afpacket plugin, so I > know the Zeek code is OK. > > >> On Jul 12, 20

Re: [Zeek-Dev] updating intelligence data without restarting Zeek

2019-03-14 Thread Jan Grashöfer
Hi Mauro, On 14/03/2019 07:50, Mauro Palumbo wrote: > However, I noticed that this works fine if new fields are added to the > intel data file, but NOT if some fields are removed (for example if an > ip address previously believed to be malicious is removed from the intel > file because it was

Re: [Zeek-Dev] Using a BiF across C++ and Zeek Policy

2019-03-13 Thread Jan Grashöfer
On 12/03/2019 17:15, zeo...@gmail.com wrote: > I am working on improving the btests for the kafka writer plugin with the > goal of validating some logic in KafkaWriter::DoInit. The best approach > that I have so far is to write a BiF and use it in both DoInit and the > btest via Zeek policy, but I

Re: [Zeek-Dev] Hi + LL Analyzer

2019-02-28 Thread Jan Grashöfer
On 27/02/2019 20:40, Robin Sommer wrote: >> One question here would be whether it makes sense to assume that the set of >> LL-analyzers tash should be available is known at compile-time? > > The built-in ones can be known, but any added through dynamic plugins > can't really. We'll know only at ru

Re: [Zeek-Dev] Hi + LL Analyzer

2019-02-27 Thread Jan Grashöfer
On 26/02/2019 02:36, Robin Sommer wrote: > I see three pieces here overall that I think can be tackled > independently: > > (1) Link-layer: Currently hardcoded in Packet::ProcessLayer2() > > (2) IP-Layer: Currently hardcoded in NetSessions::NextPacket() > > (3) Transport-layer: Currently hardcod

Re: [Zeek-Dev] Hi + LL Analyzer

2019-02-07 Thread Jan Grashöfer
To add a bit more context: The idea is to implement a plugin interface for low-level analyzers (see https://github.com/zeek/zeek/issues/248) and collect requirements on the list. Some first thoughts and questions: - What would be the lowest layer to built up on or should everything be pluggable

Re: [Zeek-Dev] support for event handlers using a subset of parameters

2019-02-07 Thread Jan Grashöfer
On 06/02/2019 21:00, Jon Siwek wrote: > On Wed, Feb 6, 2019 at 1:30 PM Vlad Grigorescu wrote: > >> I _think_ I like Seth's idea of records, but I'm still thinking it through. >> It would formalize a growing trend towards moving more parameters into >> records anyway. If we're worried about back