[pcap-ng-format] Some questions about the pcapng draft

[Jasper Bongertz]

Wednesday, July 22, 2015, 3:10:51 PM, Hadriel Kaplan wrote:

> 1) Can there be multiple opt_comment options for the same block?
> (i.e., can you add a second, third, fourth, ...)

I think so - at least I don't think I've seen anything not allowing
this. The question is - do we want to limit comments to a single
block? Or, the other way around, is there any need for multiples?

The only reason I can think of to use multiple comments if abusing
them for something else, e.g. if I want an option for "this packet was
sanitized" and it doesn't exist (or won't be added, for whatever
reason). But in that case I'd prefer adding a specific option instead
of abusing comments ;-)

> 2) Are IPv4 address fields in all blocks/options always encoded in
> network byte order? (since some programs internally represent them as
> a uint32_t, this should be indicated in the draft)

Good question - I think so far they are, but it is a good idea to
specify this specifically. We must not mix representations here.

> 3) For the Section Header Block’s shb_hardware, shb_os, and
> shb_userappl options: should/must capture file re-writers replace
> these values? For example, should mergecap replace them when it merges
> two pcapng files? Should tshark/Wireshark replace them, if they had
> filtered out some packets from the original pcapng file? What if it
> only converts from pcapng version X to future pcapng version Y?

That is something I asked a while ago, too. My idea would be to keep
the original values no matter what (because I do like to know the
original capture situation) and add an option to the next version like
"shb_editor" that can be added when files are merged/edited/sanitized.
Right now TraceWrangler and Mergecap both write into the file comment
option instead, as far as I remember.

> 4) Should capture file re-writers pass-through unknown blocks and
> options, or should they remove them? If they copy/keep them, the
> endianess of their payloads may get screwed up.

My preference would be to remove them, and display a warning about
unknown  block  types  to  the  user  while they do.

> Perhaps question 3+4 above are out-of-scope for the draft, since it’s
> technically a file format spec not an app implementation doc. But the
> Introduction said two of the goals were “Portability” and
> "Merge/Append data”, so perhaps an appendix with recommendations for
> such actions would be useful?

Agreed.

Cheers,
Jasper
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3681 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.winpcap.org/pipermail/pcap-ng-format/attachments/20150722/f676e3e2/attachment-0001.bin>