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

[Mikhail Gusarov]

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.