<div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 1, 2016 at 3:10 AM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On May 30, 2016, at 11:35 PM, Guy Harris <<a href="mailto:guy@alum.mit.edu">guy@alum.mit.edu</a>> wrote:<br>
<br>
</span><span class="">> If a capture is done, it might be useful to record, for the machine to which the physical interface on which the capture was done is attached:<br>
><br>
> the hardware of that machine;<br>
><br>
> the OS that machine is running;<br>
><br>
> the application that did the capturing;<br>
><br>
> if they are available.<br>
<br>
</span>Given the existence of tools that merge capture files, no guarantee can be made that any option in the Section Header Block will reflect "the machine on which the capture was done", so:<br>
<br>
1) programs shouldn't report the shb_hardware, shb_os, or shb_userappl options as pertaining to the machine on which the capture was done (yes, Wireshark does that, and, yes, it should stop doing so);<br>
<br>
2) we should have IDB options for both the machine on which the capturing application was run and the machine to which the interfaces on which the captures were done was attached - the latter should probably be omitted if the interface is local;<br>
<br>
3) programs that merge captures should probably only copy over shb_hardware, shb_os, and shb_userappl options from the input files if the values are the same in all files - and that raises questions about merging multi-section files.<br>
<br>
So I'd vote for adding to the IDB:<br>
<br>
if_hardware - the hardware on the machine doing the capturing and writing the capture file;<br>
<br>
if_userappl - the application running on that machine;<br>
<br>
with if_os specified as being the OS running on that machine, and also adding<br>
<br>
if_remote_hardware - the hardware on the machine to which the interface is attached;<br>
<br>
if_remote_os - the OS running on that machine (if any);<br>
<br>
if_remote_userappl - the capturing from that interface and sending packets over the wire (e.g., rpcapd);<br></blockquote><div>I don't like _remote_ it is not possible to use _capture_ or other name ? <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
along with<br>
<br>
if_interface_hw - a hardware-level description of the adapter on which the capture is being done (local adapter for a local machine, remote adapter for a remote machine).<br>
<br>
The current description of the SHB options in question speaks of them as being for the {hardware,OS,application} "used to create the section", which, arguably, means that, in a merged capture, it should refer to the hardware and OS on which the merging program was run and the merging application itself.<br>
<br>
Whether editing a capture, by removing packets, adding/removing/changing comments, etc. should result in the SHB options being removed or changed is another question; my inclination is "no".<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
pcap-ng-format mailing list<br>
<a href="mailto:pcap-ng-format@winpcap.org">pcap-ng-format@winpcap.org</a><br>
<a href="https://www.winpcap.org/mailman/listinfo/pcap-ng-format" rel="noreferrer" target="_blank">https://www.winpcap.org/mailman/listinfo/pcap-ng-format</a><br>
</div></div></blockquote></div><br></div></div></div>