Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Inconsistent ordering of interval set elements in GetSetElements

Open
#320 0 comments 1 reaction 0 assignees View on GitHub

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

question

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

  1. 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,
	},
}
  1. Call GetSetElements to 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.
  • nft appears 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

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from google/nftables

All issues in google/nftables

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.