<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thank you for your comments.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">First, I forgot to mention that the reason Timestamp is included in this proposed block type is that if an application is not interested in timestamps it would use Simple Block types, but very often timestamps are of great interest for the purpose of analysis and replay. Moreover, obtaining timestamps is very fast (i.e. nanoseconds latency) on modern hardware, so it's worthwhile to have an "intermediate" block format between Simple and Enhanced Packet Block, that is timestamped, but doesn't have overhead of the enhanced packet.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">See inline.</div><br><div class="gmail_quote">On Sat, Aug 13, 2016 at 10:56 PM, Guy Harris <span dir="ltr"><<a href="mailto:guy@alum.mit.edu" target="_blank">guy@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> This proposal introduces the format that extends the option<br>
> definition to be able to store values in place of the option length<br>
> field, therefore reducing the size of the option code/value pair to<br>
> four octets.<br>
<br>
So this different option format would apply *only* to this block, and this block would *not* support "local use" options, as the pcapng spec already says, in section 3.5 "Options":<br>
<br>
Option Type (2 octets): it contains the code that specifies the type of the current TLV record. Option types whose Most Significant Bit is equal to one are reserved for local use; therefore, there is no guarantee that the code used is unique among all capture files (generated by other applications), and is most certainly not portable.<br>
<br>
so<br>
<br>
1) in other blocks, if the option type's high-order bit is set, it means "this is a local-use option", not "this is an option with a 24-bit value";<br>
<br>
2) in a block that uses these alternative options, if the high-order bit is set, it's a "short" option with the value in the remaining 24 bits, not a "local-use" option.<br>
<br>
If you want to have a new option type that applies to *all* blocks, and to support local-use options in the Alternative Packet Block, you would have to pick another bit to indicate a "short" option.<br>
<br>
The bit below the high-order bit isn't available, unless you treat the "do not copy this to an output file" custom options as special cases, as the option codes for those are 19372 and 19373, which have the bit below the high-order bit set. No option code currently has the bit below the bit below the high-order bit (the <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"></div>0x2000 bit) set.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">You have a good suggestion and it would make sense to make this option type portable to other blocks.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> 3.5 Options<br>
> Proposed extention to Options includes a special option value setting<br>
> the highest bit of the "Option Code" to 1 and leaving remaining 7 bits<br>
> of space for 127 possible option codes. The remaining 24 bits will be<br>
> used for storing the option's value:<br>
><br>
> 0 1 2 3<br>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<br>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
> |1| Option Code | Option Value |<br>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
><br>
> This layout saves 4 bytes for options with compact values, such as<br>
> the ones described in the following packet block.<br>
<br>
The following packet block would be the *only* one that can use it, unless you pick a different bit.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">So, with this revision, let's modify the layout of this option type, and also for the purpose of preserving alignment, let's keep the code/value 2 octets each:</div></div><div><br></div><div><div class="gmail_default"><font face="monospace, monospace"> 0 1 2 3</font></div><div class="gmail_default"><font face="monospace, monospace"> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1</font></div><div class="gmail_default"><font face="monospace, monospace">+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</font></div><div class="gmail_default"><font face="monospace, monospace">|0 0 1| Option Code | Option Value |</font></div><div class="gmail_default"><font face="monospace, monospace">+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">Hence, revised option codes become (with added apb_iface_id option):</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace"><div class="gmail_default">Options:</div><div class="gmail_default"> Name Code Length Multiple? Description</div><div class="gmail_default"> apb_opt_size 0x2001 - no Total byte size of options</div><div class="gmail_default"> apb_orig_len 0x2002 - no Packet's Original Length<br></div><div class="gmail_default"> apb_iface_id 0x2003 - no Interface ID</div><div class="gmail_default"> apt_flags 0x2004 - no Alternative Packet Block Flags</div><div><br></div></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 5.1 Alternative Packet Block<br>
> 0 1 2 3<br>
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<br>
> +-----------------------------<wbr>------------------------------<wbr>----+<br>
> 0 | Block Type = 0x00000010 |<br>
> +-----------------------------<wbr>------------------------------<wbr>----+<br>
> 4 | Block Total Length |<br>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
> 8 | Timestamp (High) |<br>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
> 12 | Timestamp (Low) |<br>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
> 16 / /<br>
> / Options (variable) /<br>
> / /<br>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
> / /<br>
> / Packet Data /<br>
> / variable length, padded to 32 bits /<br>
> / /<br>
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-<wbr>+-+-+<br>
> | Block Total Length |<br>
> +-----------------------------<wbr>------------------------------<wbr>----+<br>
><br>
> Captured Packet Length - Length of the packet<br>
><br>
><br>
> Options:<br>
> Name Code Length Multiple? Description<br>
> apb_opt_size 0x81 - no Total byte size of options<br>
<br>
If that field is present, does the option list need to end with an opt_endofopt option? There *shouldn't* be a need for it (in fact, there isn't a need for an opt_endofopt option in the current pcapng spec, as, for all the other blocks, the number of bytes of option can be calculated from the size of the block and the size - no need for a redundant terminator).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">If this field is present there's no need for opt_endofopt.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> apb_capt_len 0x82 - no Packet's Captured Length<br>
<br>
Wouldn't that be redundant, just as it is for the Simple Packet Block? You have to figure out how many bytes of option there are before you can find the beginning of the packet data and, at that point, the original size of the packet is min(snapshot length, bytes left in the block).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">Fair point. This option can be dropped.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
BTW, presumably all these packets have arrived on interface 0, as there's no interface ID field.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">Added apb_iface_id option above to signify the interface.</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 4-11 Compression type<br>
> 0 = uncompressed<br>
> 1 = lzw<br>
> 2 = gzip<br>
> 3 = bzip2<br>
> 4 = zip<br>
> 5 = 7z<br>
> 6 = lzo<br>
> 7 = ucl<br>
> 8 = snappy<br>
> ...<br>
<br>
So that indicates the form of compression used on the packet data?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">Right, to conserve space, pcap-ng writing application could choose to compress packets. One thought here is that perhaps that should be a file-level setting in the Interface Description Block rather than on the per-packet basis as proposed here?</div></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There's no <div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline"></div>FCS length field; do these packets have an FCS iff the "FCS length" field for interface 0's IDB is non-zero (so that all packets for that interface, whether they were transmitted by this host or received by this host, either have an FCS or don't have an FCS)?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">Wouldn't that frame check sequence be part of the packet data? </div> </div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Regards,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Serge</div><br></div></div></div></div>