There is a bug in the parsing the length field for an extended tag. It resulted in missing packet header entries in bacnet.log.
In bacnet-protocol.pac the extended_length.length variable can be a uint16 or a uint32. The tag_length field was declared as a uint8. In the event an extended tag had a longer value it was truncated to one byte, resulting in misparsing the tag and subsequent tags in the packet.
This change also required a couple of subsequent changes in bacnet-analyzer.pac.
After making the change this pcap and the other Atomic Write File and Atomic Read File pcaps on http://kargs.net/captures/ appear correctly in bacnet.log. Everything was done against Zeek 3.2.3 running in pcap mode.
There is a bug in the parsing the length field for an extended tag. It resulted in missing packet header entries in bacnet.log.
In bacnet-protocol.pac the extended_length.length variable can be a uint16 or a uint32. The tag_length field was declared as a uint8. In the event an extended tag had a longer value it was truncated to one byte, resulting in misparsing the tag and subsequent tags in the packet.
This change also required a couple of subsequent changes in bacnet-analyzer.pac.
I discovered the bug when looking at Atomic Write File traffic, specifically the write file in this pcap: http://kargs.net/captures/atomic-write-file.cap
After making the change this pcap and the other Atomic Write File and Atomic Read File pcaps on http://kargs.net/captures/ appear correctly in bacnet.log. Everything was done against Zeek 3.2.3 running in pcap mode.