[tcpdump-workers] New link-type for Z-Wave serial interface
Hello, I'd like to request a number for Z-Wave serial interface link type. The link-level protocol is described in section 5 of https://www.silabs.com/documents/login/user-guides/INS12350-Serial-API-Host-Appl.-Prg.-Guide.pdf Best, Mikhail. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New link-type for Z-Wave serial interface
Hello Guy, On 21 Jul 2019, at 20:28, Guy Harris wrote: The link-level protocol is described in section 5 of https://www.silabs.com/documents/login/user-guides/INS12350-Serial-API-Host-Appl.-Prg.-Guide.pdf So the packets would either be: an ACK frame, with the packet data being 1 byte of 0x06; a NAK frame, with the packet data being 1 byte of 0x15; a CAN frame, with the packet data being 1 byte of 0x18; a data frame, with the packet data beginning with 1 byte of 0x01, followed by the other fields in Figure 5? 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). 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, skipped and then another SOF might be encountered... Best, Mikhail. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] New link-type for Z-Wave serial interface
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
Re: [tcpdump-workers] New link-type for Z-Wave serial interface
Hello Guy, On 23 Jul 2019, at 3:43, Guy Harris wrote: So should we just say something such as LINKTYPE_Z_WAVE_SERIAL XXX DLT_Z_WAVE_SERIAL Serial frames transmitted between a host and a Z-Wave chip over an RS-232 or USB serial connection, as described in section 5 of the Z-Wave Serial API Host Application Programming Guide. Frames that aren't ACK, NAK, CAN, or Data frames should be treated as invalid. with "the Z-Wave Serial API Host Application Programming Guide" linking to the document you mentioned? That way, the "Frames that aren't..." part indicates that, if code that produces those frames doesn't discard them, but provides them to programs capturing the frames or reading from a file logging the frames, the code getting the frames should either ignore them or report them as invalid. Looks good for me. Best, Mikhail. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
