Hi Guy,
On 21 Jul 2019, at 23:07, Guy Harris wrote:
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)?
Not really. These bytes are useless without the framing, and there are
at most 257 of them (frame length
is a single byte).
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.
Or do you mean that if the receiver has already determined that it's
out of sync (for example, due to
losing bytes), and it waits for an 0x01 (or possibly an ACK/NAK/CAN),
it might see a 0x01 that's part
of frame data, and think that's the beginning of a frame?
This case. I only expect it to happen in the beginning: traffic over
Z-Wave is quite low, and
the protocol is full of "send a frame and wait an acknowledgement from
the chip that it was sent over
the radio" so I don't expect to ever see UART overflows here (is "UART
overflow" a thing with USB-serial
at all?).
Best,
Mikhail.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
