Hello @biswa - this went under.
When I change anything in zeek related files and try to make then it starts again from configure and make from scratch. Is there any option to get rid of this and compile only the changed files?
Hmm - this depends a bit on the files you modify, but for .pac, .cc or .h files it shouldn’t restart from the configure step. It might help if you explain which commands you run and/or which files you modify.
I am not sure if I get these values using this event dnp3_attribute_common().
Looking at the parser a bit more, one course of action would be to introduce new events dnp3_analog_input_deadband_16() and dnp3_analog_input_deadband_32() and dnp3_analog_input_deadband_sp() and raise these whenever the respective objects are set, but see below for thoughts around the data_object event.
You could take a similar approach as for FrozenAnaInputEveDPwTime and the above, introducing new types and specific events for the deadband g34 types. But, see below.
Is it a vector of values or just a value ? As it’s type is count… why I am interested because I think deadband values may be extracted (ai_dead, ai_dead_16 of dnp3-objects.pac). Please help in this area.
This is curious. The event currently handles a few selected object types only and otherwise returns 0xff as the value. You could probably extend this to handle the ai_dead-* identifiers as well.
From a usage perspective, it seems the idea is that you first handle dnp3_object_header(), keep the obj_type and then upon dnp3_response_data_object() see if it holds what you expect.
There may be a reasonable extension to have a dnp3_typed_response_data_object(c, is_orig, obj_type, data_value) event that gives you type and data at once: Feel free to open a Github issue if this would help you.
There are few more fields needs to be extracted from dnp3 application pdu such as time value in g50 or device name/identifier in g0v247 , fragment size in g0v240 etc are not there . So I am trying to add these things. If you can help here someway will be very much appreciated.
I’d mostly be trying to replicate the existing code. For g50 it appears the AbsTime, AbsTimeInterval and Last_AbsTime don’t have a &let += { process_request } method to raise events. So taking one of the existing events and replicating it for AbsTime.
If you’re not sure about implementing these, do you have pcaps that you could share that show-case all these attributes? That would help testing.
Hope this helps and sorry for the delay,
Arne