pcap-savefile(5) in libpcap-1.10

[Denis Ovsienko <denis () ovsienko info>]

(re-sending because the first copy didn't make it to the list)

Hello all.

I have been looking through commits and the 1.10.5 section of libpcap
change log, and the recent changes to the link-layer header type field
structure look like a potential place for things to go wrong.

Specifically, the new prose says:

              P  (1  bit):  A bit that, if set, indicates that the
              Frame Check Sequence (FCS) length value is present and,
              if  not  set,  indicates that the FCS value is not
              present.

...and:

              FCS  len  (4  bits): A 4-bit unsigned value giving the
              number of 16-bit (2-octet) words of FCS that are appended
              to each  packet, if the P bit is set; if the P bit is not
              set, and the FCS length is not indicated by the
              link-layer type value, the FCS length is unknown.   The
              valid  values of the FCS len field are between 0 and 15;
              Ethernet, for example, would have an FCS length value of
              2, corresponding to a 4-octet FCS.

As far as I understand, this translates into the following 5-bit value
space (P-FCSlen):

0-0000: FCS length is unknown.
0-0001: 2-octet FCS is absent. <-- ???
0-0010: 4-octet FCS is absent. <-- ???
0-0011: 6-octet FCS is absent. <-- ???
0-0100: 8-octet FCS is absent. <-- ???
0-0101: 10-octet FCS is absent. <-- ???
0-0110: 12-octet FCS is absent. <-- ???
0-0111: 14-octet FCS is absent. <-- ???
0-1000: 16-octet FCS is absent. <-- ???
0-1001: 18-octet FCS is absent. <-- ???
0-1010: 20-octet FCS is absent. <-- ???
0-1011: 22-octet FCS is absent. <-- ???
0-1100: 24-octet FCS is absent. <-- ???
0-1101: 26-octet FCS is absent. <-- ???
0-1110: 28-octet FCS is absent. <-- ???
0-1111: 30-octet FCS is absent. <-- ???
1-0000: FCS is absent.
1-0001: 2-octet FCS is present.
1-0010: 4-octet FCS is present.
1-0011: 6-octet FCS is present.
1-0100: 8-octet FCS is present.
1-0101: 10-octet FCS is present.
1-0110: 12-octet FCS is present.
1-0111: 14-octet FCS is present.
1-1000: 16-octet FCS is present.
1-1001: 18-octet FCS is present.
1-1010: 20-octet FCS is present.
1-1011: 22-octet FCS is present.
1-1100: 24-octet FCS is present.
1-1101: 26-octet FCS is present.
1-1110: 28-octet FCS is present.
1-1111: 30-octet FCS is present.

This looks redundant, unless the case "FCS length is unknown" is not
the same as "FCS is absent".  Also it is not clear why the presence and
size of an FCS are not details of the LINKTYPE_ specification.  Also do
link-level types exist that have FSC size not a multiple of 2 octets or
more than 30 octets?

Since the high 16 bits of this field come from a WIP document, it seems
likely the encoding will change before settling, so for the purposes of
the next 1.10.5 release it would make the most sense to say how NOT to
use the high 16 bits (set to zero when writing, ignore when reading).
This way, if some unfortunate OS distribution bakes libpcap 1.10.5 into
a "supported" release and does not update it for the next 5 years, the
stale man page will still accurately tell how to use the file format in
a forward-compatible manner.

I am going to update the man page in the libpcap-1.10 branch to make it
as forward-compatible and safe as possible in libpcap 1.10.5.  If
anybody has any objections, please make your point before long.

-- 
    Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers () lists tcpdump org
To unsubscribe send an email to tcpdump-workers-leave () lists tcpdump org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s