Hello.
I’ve included a “write-up” of the problem issue in the attached .zip file
(see the enclosed “zeek_warning.txt” file)
Thanks!
zeek_script_warning.zip (7.02 KB)
Brett, email with zip attachment is blocked by many enterprise email servers due potential attacks (e.g. trojan horse). Anyway you can just send the text file or highlight the main issues?
Do you happen to be simultaneously using/developing multiple plugins
with a ZEEK_PLUGIN_PATH environment variable that points to each
plugin's build/ directory in their respective source-trees ?
If not, may need more details on how to reproduce what you're seeing.
If so, the warnings are harmless (unless you really are caring about
documentation-specific stuff) and you can set the
ZEEK_DISABLE_ZEEKYGEN environment variable to avoid the warnings while
doing plugin development. Ultimately it would be nice if Zeek could
handle this situation automatically, except I'm not immediately
thinking of a robust way to do it (might just be something to
document), so feel free to report as a GitHub issue.
- Jon
Jon,
Thanks for the tip 
my ZEEK_PLUGIN_PATH environ. variable pointed to:
/Users/ddragos/Downloads/dev/ics_zeek_parsers
Below the ics_zeek_parsers" directory, there were two subdirectories, i.e.
zeek_profinet_io_parser
zeek_ecat_parser
I moved the “zeek_ecat_parser” to another parent directory, and the warnings no longer appear.
By default, a dash ('-') in log files signifies absence of a value
(e.g. for &optional record fields), so to avoid ambiguity with '-' in
other contexts (e.g. a string with a value of "-"), those others get
escaped as \x2d.
You could change the default character used for absent values via a
'redef' of `LogAscii::unset_field` to something else:
There is also a `LogAscii::empty_field` option to control what an
empty value looks like in the log:
An empty-string would render as "(empty)" in logs by default, so maybe
you want to stick with that in your scripts instead of trying to use a
dash ('-') since that already conflicts with the default value of
unset fields. Or you could pick a different sentinel value than '-'
to use in place of empty-strings in your particular script.
Also, if you were to change either setting, note that escaping will
still happen for any logged-value found to conflict with the new
settings.
- Jon
Jon,
Thank you for the guidance.
I remember now, why I started to pass in my own “-” for empty fields.
When I pass certain variable values through to a main.zeek script event handler, I receive
error messages from the scripting layer (i.e. “…value used but not set”).
If I pass an empty string (i.e. a C string with a ‘\0’ in the first array position), I see the “value used but not set” warning.
Also, for some reason, I’m now seeing the same error, when I pass a 0 value to my “serial_low” event parameter.
(The serial_low is of type “Count” in the event handler)
(Also, serial_low is the last parameter to the event handler)
I’ve attached the stdOut and stdErr output from my zeek cmd execution.
Thanks!
–Brett
error_on_unset_vars.txt (3.02 KB)
I wouldn't think those warnings have anything to do with trying to
generate event arguments with those particular values. My intuition
is to double-check the code which generates the events to ensure it's
not unintentionally passing too few arguments or a null value.
- Jon
Jon,
Your intuition was correct.
On the “serial_low” parameter error, I was missing one parameter in the Zeek event_mgr.Enqueue() call.
(I thought that an error would be reported, if I passed an incorrect number of arguments to the Enqueue() call,
but I was mistaken. )
In the future, could Zeek report an error, if the Enqueue() call arg count doesn’t match
the args listed (for the corresp. event) in the events.bif file? Just a thought…
Next item:
For the empty pn_IO_status_str string variable…
I had seen some code in the Zeek core source files, that I had imitated incorrectly.
In that code, if the length of the “C string” was zero, they had returned a NULL ptr.
As I learned…
A NULL ptr value generates an error in the Zeek scripting layer (for script function parameters of type “String”)
To correct the problem, I
- Created a StringVal object (that had a “C string” of length zero)
- Created an IntrusivePtr to the StringVal object
- Passed the IntrusivePtr paramter to the event_mgr.Enqueue() call.
Thanks for your insight.
–Brett