Re: [babel] info-model: message log

["STARK, BARBARA H" <[e-mail]>]

Getting back to this after the holidays...

> >> Here is my suggestion for having a message log:
> >
> >> babel-message-log is:
> >> A reference or url link to a file that contains a timestamped log of
> >> messages received and sent on babel-udp-port on all interfaces. File format
> >> MUST be readable by Wireshark 1.8 or later and use the applicable file format
> >> extension in the filename. Logging is enabled / disabled by babel-message-
> >> log-enable.
> >
> > Wireshark supports multiple formats, I'm not sure that it's a good
> > idea to allow all of the formats supported by Wireshark.

Why not? Not that I'm arguing strongly for allowing all formats; just that I can't convince myself of a strong argument against it. I'm fine with a more limited set, but don't want to be too limiting. Personally, I'm fine with anything that I can get an easy-to-use, free, good parser for and that can provide all the info.

> > I'm not intimately familiar with the capture packet formats.  The
> > pcapng file format appears to be the preferred format for wireshark,
> > but the internet-draft is expired since 2014; what's more, I'm not
> > sure it's supported by libpcap.

Per https://wiki.wireshark.org/Development/LibpcapFileFormat (with a last edited date from 2015):
"It is widely accepted that the libpcap file format serves its purpose but lacks some useful features. There's a next generation pcap file format documented at the pcapng specification Git repository. The new format supplies many of the capabilities listed in "Drawbacks" above.
Wireshark currently has the ability to read and write pcapng files, and does so by default, although doesn't support all of the capabilities of the files. Libpcap 1.1.0 and later have a limited ability to read them as well, although libpcap doesn't yet supporting writing them."
 
> Would agree that the capture format is a pcap file. I will not be surprised if
> Wireshark does not understand Babel protocol, particularly if no one has
> defined it in libpcap. Not too difficult to add though.

The RFC6126 dissector exists: https://www.wireshark.org/docs/dfref/b/babel.html
I'm hopeful someone will contribute the updated dissector once the new RFC is published...

> > The traditional libpcap format is documented here:
> >
> > <url mauled by AT&T security filters>
> >
> > and it's likely to be supported by any tool in existence.  Unless
> > somebody has good technical reasons to avoid libpcap, I suggest we
> > should mandate that format.

Apparently, libpcap is said (by https://wiki.wireshark.org/Development/LibpcapFileFormat) to have the following drawbacks:
"The libpcap format is very simple, one of the reasons that it has gained such a wide usage. Unfortunately it misses a few things which would be helpful:
    nanosecond time resolution
    user comments: "shows connection breakdown starting at packet 1432"
    interface information (like the network card manufacturer)
    packet drop count (and probably other counts as well)"

I don't find any of these to be showstoppers for this proposed use. But I go back to my original premise that I'm struggling to figure out why there's a need to limit the file format.
Barbara

> >
> > -- Juliusz
> >
> > _______________________________________________
> > babel mailing list
> > [e-mail]
> 
> Mahesh Jethanandani
> [e-mail]