Is the if_fcslen option in the Interface Description Block in units of bits or bytes?

[guyharris]

The Interface Description Block description in the pcapng specification says that the if_fcslen option's value for the FCS length is in units of bits.

Wireshark, however, treats it as if it's in units of bytes.

Are there any programs that write out an if_fcslen option in the Interface Description Block? If so, does they write it out in units of bits or bytes?

[antcodd]

There is some code in Wireshark erf.c that sets OPT_IDB_FCSLEN from ERF Provenance metadata to the number of bits, but it doesn't look like Wireshark actually writes this option out to PCAPNG. The only place it is currently displayed is in capinfos output. I was surprised to see that wireshark doesn't actually use the if_fcslen for setting the linktype's FCS automatically for non-pcap(ng), might explain why we've had trouble with detecting FCS in ERF in the past.

Is there any code that writes if_fcslen for Wireshark to have read? It looks like neither Wireshark nor libpcap do. Endace's dagconvert pcapng I/O module also currently doesn't. Libtrace (which doesn't seem to be in the known implementations list) only recently added PCAPNG write support and it appears to currently be passed through, although they're working on a metadata api. Not familiar with the other implementations. I would have thought specifying FCS would have been one of the most common options to specify after name and timestamp resolution since it affects the way the file is read, rather than guesswork.

[guyharris]

There is some code in Wireshark erf.c that sets OPT_IDB_FCSLEN from ERF Provenance metadata to the number of bits, but it doesn't look like Wireshark actually writes this option out to PCAPNG.

Currently, it doesn't.

The only place it is currently displayed is in capinfos output. I was surprised to see that wireshark doesn't actually use the if_fcslen for setting the linktype's FCS automatically for non-pcap(ng), might explain why we've had trouble with detecting FCS in ERF in the past.

It saves if_fcslen in the per-file private structure - it's initialized to -1 and set if there's an if_fcslen option - and, for an EPB or PB, it starts out assuming the FCS is the value of if_fcslen and, if there's an epb_flags of pack_flags option with a non-zero FCS length, overrides the default with that value.

That value is set in the pseudo-header structure for WTAP_ENCAP_ETHERNET, and that value is used; it's not provided for any other link-layer type.

Is there any code that writes if_fcslen for Wireshark to have read? It looks like neither Wireshark nor libpcap do.

*Shark don't; tcpdump.org libpcap doesn't write pcapng files, and I don't see any code in the last open-source version of Apple's libpcap to indicate that it writes any IDB options.

Endace's dagconvert pcapng I/O module also currently doesn't. Libtrace (which doesn't seem to be in the known implementations list) only recently added PCAPNG write support and it appears to currently be passed through, although they're working on a metadata api.

I couldn't see anything in libtrace that would write it.

Not familiar with the other implementations. I would have thought specifying FCS would have been one of the most common options to specify after name and timestamp resolution since it affects the way the file is read, rather than guesswork.

Unfortunately, it won't affect Wireshark correctly if it's written according to the current spec - the value from if_fcslen isn't divided by 8 to convert from bits to bytes, and it's provided as the FCS length in the Ethernet pseudo-header, but the Ethernet dissector expects it to be in units of bytes, not bits.

[Qtsho]

Hello everyone, are there any updates on this concern? we also have a commercial tool that export pcapng file and write the if_fcslen block in IDB as bit unit. This would cause problem at Wireshark side at ethernet dissector.

[guyharris]

Code that reads pcapng files can probably infer whether a given FCS length value makes sense as a value in bits or a value in bytes, so perhaps:

• the spec should say that readers SHOULD treat obviously-too-small FCS length values as if they are in bytes;
• Wireshark should be changed to do that and treat other values is being in bits, and that change should be backported to Wireshark releases going back to 3.6.

[guyharris]

There is some code in Wireshark erf.c that sets OPT_IDB_FCSLEN from ERF Provenance metadata to the number of bits

So ERF_META_TAG_fcs_len is in units of bits?

(And how can I get a copy of EDM04-42 Provenance Guide, so that I don't have to ask about Provenance metadata tags?)

[guyharris]

Wireshark should be changed to do that and treat other values is being in bits, and that change should be backported to Wireshark releases going back to 3.6.

Done.