[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
On Jul 21, 2019, at 9:23 AM, Mikhail Gusarov wrote: > 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 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? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Link-Layer Header Type request: USB 2.0
Hello, I would like to request a Link-Layer Header Type for USB 2.0 packets. This is intended to be used as a export format from sigrok. While sigrok contains code to convert D+/D- signals into LINKTYPE_USB_LINUX_MMAPPED, it is a bit limited. One issue is that without dissecting USB Configuration Descriptor, it is impossible to determine endpoint type for non-split transactions. Another issue that without knowing endpoint maximum transfer size (also found in Configuration Descriptor), it is not possible to accurately determine short transfers and thus convert multiple transactions into transfer. If the user is not familiar with these limitations it can be really confusing. I am currently working on OpenVizsla dissector for Wireshark. While LINKTYPE_OPENVIZSLA packets can contain USB 2.0 packets, they also do contain information that is specific to the OpenVizsla itself. The dissector code I have written so far clearly separates OpenVizsla from USB Link-Layer and thus I believe it makes sense to have a separate direct entry point for USB 2.0 packets. The new Link-Layer Header Type is supposed to contain the USB 2.0 packets. That is, anything that appears on the bus between the Start- and End-of-Packet delimiters. The packet format is described in Chapter 8 Protocol Layer of Universal Serial Bus Specification Revision 2.0. Best Regards, Tomasz Moń ___ 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
On Jul 21, 2019, at 1:14 PM, Mikhail Gusarov 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. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Link-Layer Header Type request: USB 2.0
On Jul 21, 2019, at 12:40 PM, Tomasz Moń wrote: > I would like to request a Link-Layer Header Type for USB 2.0 packets. It looks as if USB 3.1's packets are different from USB 2.0's packets, so this would be 2.0-specific. > The new Link-Layer Header Type is supposed to contain the USB 2.0 > packets. That is, anything that appears on the bus between the Start- > and End-of-Packet delimiters. The packet format is described in > Chapter 8 Protocol Layer of Universal Serial Bus Specification > Revision 2.0. So that's the PID as the first byte and continuing from there? ___ 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
On Jul 21, 2019, at 1:27 PM, Guy Harris wrote: > > On Jul 21, 2019, at 1:14 PM, Mikhail Gusarov wrote: > >> 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? ___ 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] Link-Layer Header Type request: USB 2.0
On Sun, Jul 21, 2019 at 10:47 PM Guy Harris wrote: > It looks as if USB 3.1's packets are different from USB 2.0's packets, so > this would be 2.0-specific. USB 3 operates on different hardware signals. USB 3 hubs do contain USB 3 and USB 2.0 hubs inside them. The USB 2.0 data is sent on the D+/D- differential pair, while the USB 3 data uses dedicated Superspeed differential pairs for RX and TX. Valid USB 1.0 and 1.1 packets can be dissected as USB 2.0. However, this is not always true the other way round. For example USB 1.1 device won't understand SPLIT packet. Fortunately compliant USB 2.0 Host won't ever send SPLIT to the USB 1.1 device as this PID can only be sent on High Speed link (which was introduced in USB 2.0). USB 1.0 and 1.1, did feature Low- and Full- speed transmission speeds. USB 2.0 features Low-, Full- and High- speed transmission speeds. As the proposed Link-Layer Header Type operates on packet level, it has no information about the speed the packet was transmitted at. > > The new Link-Layer Header Type is supposed to contain the USB 2.0 > > packets. That is, anything that appears on the bus between the Start- > > and End-of-Packet delimiters. The packet format is described in > > Chapter 8 Protocol Layer of Universal Serial Bus Specification > > Revision 2.0. > > So that's the PID as the first byte and continuing from there? Yes. PID is 4 bits long. The first byte contains PID and completed PID. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
