Skip to content

Conversation

@johnthacker
Copy link
Contributor

It is two octets, not one octet, to pad to a 32-bit boundary. That
matches observed captures, and also see:

https://github.com/torvalds/linux/blob/master/include/uapi/linux/netfilter/nfnetlink_log.h#L27

https://github.com/the-tcpdump-group/libpcap/blob/master/pcap/nflog.h#L64

Signed-off-by: John Thacker <johnthacker@gmail.com>
@infrastation
Copy link
Member

The address field does not look consistent either: it says "8 Octets, including padding", but both of the linked C structures show it as an array of 8 bytes. tcpdump NFLOG decoder declares it as 8 bytes too, although it does not seem to decode hardware addresses.

@johnthacker
Copy link
Contributor Author

In my sample captures, it's always 8 bytes, and (since it's usually an Ethernet EUI-48 address) the "Address Length" field has the value 6, there are two bytes of padding, then the "Address" field has 6 bytes for the address and two more bytes of padding within that field. Presumably for a EUI-64 address there would be no padding in the 8-byte Address field.

@johnthacker
Copy link
Contributor Author

So I think the Address field is "8 Octets, truncated or padded with zeroes as necessary." Procrustean.

@infrastation infrastation merged commit b6d1d42 into the-tcpdump-group:master Nov 23, 2025
1 check passed
@infrastation
Copy link
Member

Thank you.

infrastation added a commit that referenced this pull request Nov 23, 2025
Based on additional comments by John Thacker in pull request #48.

[skip ci]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants