The functionality added in a46119e5 never worked: If you set
NFTA_RULE_POSITION to 0, the kernel will just complain that a rule with
this handle does not exist. This removes the broken functionality,
leaving the field deprecated.
The right way to insert a rule at the beginning of a chain is to use
InsertRule and leave Position unset.
https://github.com/google/nftables/issues/126 mentions that the nft
command allows referring to rules by index. But here is a quote from the
nft manpage:
> The add and insert commands support an optional location specifier,
> which is either a handle or the index (starting at zero) of an
> existing rule. Internally, rule locations are always identified by
> handle and the translation from index happens in userspace.
In other words, identifiying rules by index is a feature of nft and is
not part of the kernel interface.
This change makes it possible to delete rules after inserting them,
without needing to query the rules first. Additionally, this allows
positioning a new rule next to an existing rule.
There are two ways to refer to a rule: Either by ID or by handle. The ID
is assigned by userspace, and is only valid within a transaction, so it
can only be used before the flush. The handle is assigned by the kernel
when the transaction is committed, and can thus only be used after the
flush. We thus need to set an ID on each newly created rule, and
retrieve the handle of the rule during the flush.
I extended the message struct with a pointer to the Rule which the
message creates. This allows calling the reply handler callback which
sets the handle.
I updated tests to add a handle to generated replies for the
NFT_MSG_NEWRULE messages.
Commit 0d9bfa4d18 added code to handle "overrun", but the commit is
very misleading. NLMSG_OVERRUN is in fact not a flag, but a complete
message type, so the (re&netlink.Overrun) masking makes no sense. Even
better, NLMSG_OVERRUN is never actually used by Linux.
The actual bug which the commit was attempting to fix is that Flush was
not receiving replies which the kernel sent for messages with the echo
flag. This change reverts that commit and instead adds code in Flush to
receive the replies.
I updated tests which simulate the kernel to generate replies.
The ID allows referring to a rule before it is committed, as
demonstrated in the newly added test.
I had to update all existing tests which compared generated netlink
messages against a reference, by inserting the newly added ID attribute.
* Close receiver for lasting netlink connections while defaulting to existing temporary netlink connection usage
* add unit test for New lasting connection, Close and correct default connection handling behavior
* refactor tests to use New constructor
* make Conn mutex un-exported (#159)
fixes issue #157
* Unmarshal Exthdr and support DestRegister/Flags for reads
Some fields in Exthdr are context-sensitive. Mixing unexpected fields
will result in EOPNOTSUPP.
* Fix order in which Exthdr attributes are written