Inconsistent ordering of interval set elements in GetSetElements
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 42/100
- Issue type
- Bug
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- go, linux
- Domain
- networking
Research direction
Start with the reproduction in nftables_test.go around line 7433, then trace GetSetElements and how it handles elements received from netlink. Compare the returned order with the interval-boundary expectations in the issue. Done means the ordering behavior is established and covered by a focused regression test, with the implementation or documentation updated accordingly.
Written by the indexing model from the issue text.
Description
When retrieving set elements that include intervals via GetSetElements, I've observed inconsistent ordering of elements with the IntervalEnd flag. Sometimes the IntervalEnd element appears before its corresponding interval start, and sometimes it appears after, which is unexpected and inconsistent.
Steps to reproduce
- Given the following set elements:
elements := []nftables.SetElement{
// 10.0.0.0/24
{
Key: net.IPv4(10, 0, 0, 0).To4(),
},
{
Key: net.IPv4(10, 0, 1, 0).To4(),
IntervalEnd: true,
},
// 1.1.1.1/32
{
Key: net.IPv4(1, 1, 1, 1).To4(),
},
{
Key: net.IPv4(1, 1, 1, 1).To4(),
IntervalEnd: true,
},
}
- Call
GetSetElementsto retrieve the set elements.
Observed behavior
The returned elements are ordered inconsistently:
elements := []nftables.SetElement{
// 10.0.0.0/24
{
Key: net.IPv4(10, 0, 1, 0).To4(),
IntervalEnd: true, // IntervalEnd appears before the interval start
},
{
Key: net.IPv4(10, 0, 0, 0).To4(),
},
// 1.1.1.1/32
{
Key: net.IPv4(1, 1, 1, 1).To4(),
},
{
Key: net.IPv4(1, 1, 1, 1).To4(),
IntervalEnd: true, // IntervalEnd is in the expected position
},
}
I've created a test case that demonstrates this in detail: https://github.com/nickgarlis/nftables/blob/test-set-elements-order/nftables_test.go#L7433
Question
Is this ordering behavior expected, or could it be a bug in the GetSetElements implementation? Could it be that the elements are simply returned in the order they are received from netlink ? I briefly looked through the source code but didn’t see any obvious logic handling element sorting.
Notes
- I noticed this behavior because I was trying to parse some existing set elements which is a little tricky now.
nftappears to sort set elements when displaying them in CIDR notation. By contrast, this library returns elements in their order of creation. Should this library consider adopting nft’s approach ?
Edit:
After opening this issue, I realized I made a mistake in the 1.1.1.1/32 example. I had used two elements with the same key, which likely caused the unexpected behavior with interval boundaries.
The correct elements for that interval should have been:
{
Key: net.IPv4(1, 1, 1, 1).To4(),
},
{
Key: net.IPv4(1, 1, 1, 2).To4(),
IntervalEnd: true,
},
That said, the elements are still being returned in reverse order which might be worth discussing. I am leaving the issue open in case others have insights or opinions about this.
- Dominant language
- Go
- Stars
- 1.4k
- Forks
- 187
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from google/nftables
-
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
-
Multiple Netlink Decode Paths Can Panic on Malformed or Undersized InputPossibly taken @vulragrag-star claimed this 31 days ago. Open
Difficulty 4/5 3-5 days Newbie friendliness 68/100
-
New Tag release.Open
Difficulty 3/5 1-2 days Newbie friendliness 45/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Similar issues
-
kind/bug
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
kubevirt/kubevirt#19559 · 1 reaction ·
Maintainers usually reply within 1 day
-
bug raised-by:verifier
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
medici-finance/assay#3817 ·
Maintainers usually reply within 1 day
-
automation models
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
gtsteffaniak/filebrowser#3244 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
QuantumNous/new-api#7930 ·
Maintainers usually reply within 1 day