On Jul 21, 2019, at 1:14 PM, Mikhail Gusarov <dotted...@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. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
