On Jul 25, 2018, at 1:47 AM, David Mirabito <dav...@metamako.com> wrote:
> I have attached a more detailed description as a text file (lest email mangle > the ASCII-art), but in short, a packet would look on the wire like: > > * SOF > * Destination address > * Source Address > * EtherType/Length > * Payload > * FCS . <--- everything up to, and including, here is unmodified by > MetaWatch. Typically our appending a trailer may allow this FCS to be > captured by NICs which would otherwise have stripped it So an Ethernet frame passes through one of your K-series devices, and it takes the entire frame, appends a trailer, and sends it out for something else to capture, so that the original FCS is part of the new packet's payload, and is thus always present? > * Optional Extension TLVs > * Timestamp: Seconds > * Timestamp: Nanoseconds > * Flags (currently whether FCS was correct at ingress, and presence of any > extension TLVs) > * Device ID (by default unique portion of the device's serial number) > * Port ID > * NewFCS (calculated so that metawatch emits a valid frame, not always > captured by capturing NICs) > * EOF > > The intent when parsing is that the base trailer is always the last 12 bytes > so given a complete capture one may simply skip directly to "wlen - 12", so > there is no need to interpret EtherLen, or do a full dissection to locate the > trailer. I agree that the case where caplen < wirelen may be problematic, but > then you're guaranteed a corrupted or missing trailer anyway so it might not > be worth even trying. Well, if len - caplen < 12, you know that 12 - (len - caplen) bytes of the base trailer are present, so you can extract the parts that *are* present. If it's >= 12, none of the base trailer is there, so you don't know whether there are extensions, and you can't parse the extensions. _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
