Hi Denis,
> ---- On Fri, 13 Jul 2018 08:40:47 +0100 Denis Ovsienko <de...@ovsienko.info>
> wrote ----
> > ---- On Thu, 12 Jul 2018 20:38:08 +0100 Guy Harris <ghar...@sonic.net>
> wrote ----
> > > On Jul 12, 2018, at 11:33 AM, Petr Vorel <pvo...@suse.cz> wrote:
> > > > +#ifdef PCAP_SUPPORT_SLL_V2
> > > > + char ifname[IF_NAMESIZE];
> > > > + if (if_indextoname(EXTRACT_BE_U_6(sllp->sll_ifindex), ifname))
> > > > + ND_PRINT("IFNAME %s ", ifname);
> > > > +#endif
> > > What happens if you capture traffic on machine A and print it on
> machine B, where machines A and B have different sets of network interfaces?
> > > (This is why pcapng has Interface Description Blocks - so that the list
> of interfaces is part of the file, so you use *that*, rather than the
> configuration of interfaces on the machine running the program reading the
> capture, to get interface names.)
> > What if the MBZ field of SLL2 encoding was first, and its values meant the
> following:
> > * 0x0000: the rest of the packet structure is a packet (like it is now)
> > * 0x0001: interface X exists, has name Y and is up (down) and is (is not)
> in promiscuous mode
> > * 0x0002: interface X no longer exists
> > Then in future it will be possible to interleave packet events with
> interface events. At the start of the capture it will be possible to have a
> sequence of interface declarations before any packets, and later on it will
> be possible to encode the interface name changes in the middle of the packet
> events. Then it will be possible to record the sequence of the events and
> interface names more or less accurately (less the synchronization between the
> capture buffer and the netlink socket), and to replay later.
> > I am not saying it should be implemented anytime soon, just making the
> point it is easy to make the space for this future extension in the SLL2
> encoding right now.
> In addition to the above:
> * 0x0003: start of capture mark (possibly with an ASCII copy of the filter
> expression)
> * 0x0004: end of capture mark
> ...or simply:
> * 0x0003: timestamp mark
> (as proposed a few months ago, such that it is possible to tell what exact
> time span a .pcap file covers, not just what the timestamps of the first and
> the last packets are)
Although even my implementation in
https://github.com/the-tcpdump-group/tcpdump/pull/689 would be nice improvement,
these changes would be even better.
Kind regards,
Petr
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
