Hi Guy, Thanks for the comments, addressed inline:
> 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? Correct. The typical use case is for Ethernet stream(s) to pass through the box unmodified, and internally we can Tap & Aggregate with metadata appended some/all of these. The "something else" might be our on-board management platform, or (more commonly) the aggregate stream is fed out a port to a dedicated capture/persist/analytics appliance, some of which currently do interpret the trailer. > > * 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. This is true, and a good idea. To be fair, my current prototype doesn't do that, but will add such robustness to any submitted code implementing the proposed DLT. Thanks again, David _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
