Actions
Bug #12703
closedpf ``hostid`` value is handled inconsistently
Status:
Resolved
Priority:
Very Low
Assignee:
Category:
Operating System
Target version:
Start date:
Due date:
% Done:
0%
Estimated time:
Plus Target Version:
22.05
Release Notes:
Default
Affected Version:
Affected Architecture:
Description
We don't use this yet, but we should in the future (See #12702) but I've noticed an inconsistency in how pf handles the hostid/creator ID.
If you manually set a host ID in the pf rules like so:
set hostid 0x12345678
Then pf outputs that value differently:
pfctl -vvss | grep creator [...] id: 127ee96100000000 creatorid: 78563412 gateway: 198.51.100.1 [...]
Note the byte order is reversed, it is 0x12345678
in the ruleset but 78563412
in the state table data.
When passing an ID to pfctl
to kill a state from that creator, it only accepts the reversed form:
: pfctl -k id -k 127ee96100000000/0x12345678 killed 0 states : pfctl -k id -k 127ee96100000000/0x78563412 killed 1 states
Similarly, if you specify an ID in decimal form (set hostid 1
) it comes out as 01000000
instead.
Related issues
Updated by Jim Pingle almost 3 years ago
- Related to Feature #12702: Use consistent pf host ID and add GUI option to set a custom host ID in state synchronization settings added
Updated by Kristof Provost almost 3 years ago
Updated by Jim Pingle over 2 years ago
- Status changed from New to Resolved
- Target version changed from CE-Next to 2.7.0
This is good on the latest snapshot which was built after our recent upstream merge.
: grep hostid /tmp/rules.debug set hostid 0x1 : pfctl -vsi | grep -i host Hostid: 0x00000001 :pfctl -vvss [...] all icmp 198.51.100.12:24252 -> 198.51.100.1:24252 0:0 age 00:00:02, expires in 00:00:10, 5:5 pkts, 145:145 bytes, rule 103 id: fe29336200000000 creatorid: 00000001 gateway: 0.0.0.0 origif: vtnet0 [...] : pfctl -k id -k fe29336200000000/1 killed 1 states
Actions