[pcap-ng-format] The "scope" of the Name Resolution Block

Guy Harris guy at alum.mit.edu
Wed Sep 2 03:27:16 UTC 2015


On Sep 1, 2015, at 6:54 PM, Hadriel Kaplan <the.real.hadriel at gmail.com> wrote:

> How about a "Interface Event Block", which has as its fixed data the
> Interface ID, timestamp, and Event Type which is one of:
> 0 = Link Up
> 1 = Link Down
> 2 = Enabled
> 3 = Disabled
> 4 = Info Changed

At least two file formats (i4b, i.e. ISDN4BSD, and EyeSDN - yes, there's a theme here :-)) have layer 1 event records that have descriptive text as the contents (EyeSDN also has a direction indication, which I guess is user->network or network->user).

Should we support something such as that, or should we use custom blocks for them?  It *might* be useful to tie them to an interface (although nothing forbids a custom block from including an interface ID).

> For the last one "Info Changed", the options in the block replace the
> existing ones - i.e., if the interface already had an IPv4 address and
> a new one got added, this block will have both the old and new one; if
> the old one got replaced by the new one, this block has just the new
> one; if the old one went away without a replacement, this one has no
> if_IPv4addr option. I would, however, like to restrict it so that
> if_tsresol, if_tzone, if_fcslen, and if_tsoffset cannot be changed
> this way; they require creating a new IDB or a new SHB and IDB. (it's
> really complicated to handle those things changing in the middle of an
> SHB otherwise)

I'd prefer not to have to start a new section just because I clamshelled my laptop, with Wireshark running, in San Francisco, and reopened it in New York, so it might be nice to at least try to support changes to if_tzone - and to any future option with an IANA tz database tzid - in the process.

The application would have to manage its own map of packet ranges to time zone information, but it'll see the Info Changed messages, so it's at least *capable* of doing so.

For the others, yes, I see no reason why there would be a reason to expect the time stamp resolution to change out from under a live capture, and if the FCS length (e.g., PPP, if the FCS is supplied to the capture mechanism, and it gets negotiated) changes, that can show up in the packet block.


More information about the pcap-ng-format mailing list