[tcpdump-workers] New link-type for Z-Wave serial interface

Guy Harris gharris at sonic.net
Sun Jul 21 16:27:52 EDT 2019

On Jul 21, 2019, at 1:14 PM, Mikhail Gusarov <dottedmag at dottedmag.net> wrote:

> That's right. Also there might be some garbage frames at the beginning of capture
> (basically, the contents of the current packet up to ACK/NAK/CAN/data).

So a "garbage frame" would be any frame that begins with a value other than 0x06, 0x15, 0x18, or 0x01?

Is there any reason for whatever capture mechanism produces these packets not to discard garbage frames rather than handing them to the libpcap caller (if this is implemented as a libpcap module) or writing them to a file (if this is implemented as a program that writes pcap or pcapng files)?

> Now that I think about it, in a very rare case it is possible to not be able to synchronize at all:
> if a SOF byte is encountered inside the data frame, then the next byte will be interpreted as a length,

If by "SOF byte" you mean "byte with the value 0x01", then an SOF byte will be encountered inside every frame of type Response, so it seems pretty clear that a data-frame-reading algorithm of "read and accumulate bytes until you see an 0x01" won't work.

More information about the tcpdump-workers mailing list