fw4: enable mac ranges for rule by ckorber · Pull Request #74 · openwrt/firewall4

ckorber · 2025-10-02T11:06:09Z

nft supports handling mac ranges and therefore this commit changes fw4 to support that feature. The src_mac is now allowed to be a address with CIDR notation. If no CIDR notation is configured, the old logic is applied.

So this is now possible:

option src_mac '00:11:AA:BB:CC:DD-00:11:AA:FF:FF:FF'

Also negation with '!' at the beginning to block every MAC not in the range is possible.

brada4 · 2025-10-02T12:11:36Z

CIDR is wrong approach for MAC address, you have to be able to extract 2 youngest bits of oldest byte.

ckorber · 2025-10-07T06:50:52Z

So if I understand you correctly you mean that it is not useful to enable the whole range, because the first byte contains important information that should not be manipulated, am I right?

I can modify it to only allow ranges in the last three youngest bytes (so not the oui).
Is that also your intention?

brada4 · 2025-10-07T07:53:13Z

The grouping of MAC addresses with mask is very welcome, just that presuming CIDR is wrong. Yo uare on the right path, just that took a bit odd turn.
DOC: https://en.wikipedia.org/wiki/MAC_address#Ranges_of_group_and_locally_administered_addresses

Example src 00:00:00:00:00:00/01:00:00:00:00:00 drop would drop unrealistic packets sourcing from multicast addresses.

ckorber · 2025-10-07T07:55:46Z

I get what you mean, I think.
The first byte holds valuable information that shouldn't be touched.

But if I limit it to bytes after the oui, we should be safe, right?

brada4 · 2025-10-07T08:01:26Z

Just use full mask, thats all I wanted to tell. There is no CIDR for mac addresses.

brada4 · 2025-10-08T19:52:31Z

Something wrong with parentheses ;-)

ckorber · 2025-10-08T20:01:40Z

Better? :)

I dropped the CIDR approach and let it parse for ranges that are set or return as usual.
If the range is wrong (that is if the lower is on the right) it returns nothing.

~~EDIT: Oh I didn't push again.~~

brada4 · 2025-10-08T20:09:04Z

You can compile ucode and ./run_tests.sh (it is a bit tricky first time, you have to disable all or most extensions via cmake-gui or parameters)

brada4 · 2025-10-08T20:40:22Z

You dont have to check special case with 0 or -1 mask that makes no-op-ish rules

ckorber · 2025-10-09T06:23:42Z

root/usr/share/ucode/fw4.uc

 				icmp_codes: map(icmpcodes, ic => `${(family == 4) ? ic.type : ic.type6} . ${(family == 4) ? ic.code_min : ic.code6_min}`)
 			};

+			if (!length(r.smacs_pos))


You dont have to check special case with 0 or -1 mask that makes no-op-ish rules

Are you talking about these lines?

EDIT: The ./run_tests.sh was fine. All tests passed.

If I understand you correctly now, you meant that I don't have to check for correctness because fw4 already handles that, am I right?

ckorber · 2025-10-14T07:10:51Z

Does that work for you @brada4 ?

brada4 · 2025-10-14T08:35:59Z

Wait for @jow- to examine it.

This commit is a preparation to add the possibility to block or accept a range of MAC addresses int they syntax of: ''' 00:11:22:00:00:00-00:11:22:ff:ff:ff ''' The commit depends on the PR openwrt/firewall4#74 being merged first. Signed-off-by: Christian Korber <[email protected]>

ckorber · 2025-10-20T06:19:48Z

ping @jow-

systemcrash · 2025-10-29T15:25:38Z

Advise you reword commit message:
Also negation with '!' at the beginning to block every MAC not in the range is possible.
to
Also negation with '!' at the beginning to block every MAC in the range is possible.

ckorber · 2025-10-31T06:49:16Z

But I meant what I wrote?
AFAIK the '!' negates the range and applies to the opposite, so it handles every MAC not in the range.

I could change it to:
Also negation with '!' at the beginning to handle every MAC not in the range is possible.

brada4 · 2025-10-31T11:27:49Z

It is double no in your sentence meaning YES in some languages...

ckorber · 2025-10-31T11:47:26Z

If a range is specified with '!', like '!00:11:AA:00:00:00-00:11:AA:FF:FF:FF'
it handles every MAC that is not within the range.

I rephrased it. Is it now clearer?

systemcrash · 2025-10-31T12:41:53Z

Handle could be ambiguous depending on the action requested. The initial wording of ! == block (within the range) is clear and concrete. Less cognitive load.

brada4 · 2025-10-31T14:22:16Z

exclamation mark is called negation in iptables doc
eg "negative matching using exclamation mark is supported"

ckorber · 2025-11-10T11:47:38Z

@brada4 : I used your suggestion for the commit message.

Any other way to progress this PR? I think @jow- is not available at the moment.

systemcrash · 2025-11-10T12:36:57Z

One potential pitfall with ambiguity: it becomes difficult to differentiate between MAC and hyphen separator when the MACs themselves use hyphen - between octets. :)

00-11-AA-00-00-00-00-11-AA-FF-FF-FF.

Although I can't think of a better separator. Hyphen is typically used to denote ranges. If this is deemed problematic, how about underscore? No, that's a binder. Tilde?

00-11-AA-00-00-00~00-11-AA-FF-FF-FF.

Thoughts @ckorber ?

brada4 · 2025-11-10T13:04:00Z

nftables takes all imaginable formats
in

table inet t {
 chain c {
 ether saddr & 01:00:00:00:00:00 == 0x0
  ether saddr "02-00-00-00-00-00"-"04.ff.ff.ff.ff.ff"
 }
}

out

table inet t {
        chain c {
                ether saddr & 01:00:00:00:00:00 == 00:00:00:00:00:00
                ether saddr 02:00:00:00:00:00-04:ff:ff:ff:ff:ff
        }
}

0x0 in first line overflows if exceeding uint32 so it is not really useful for anything. standard format is with colon, other formats needs to be escaped.

ckorber · 2025-11-10T13:11:49Z

Hate that I didn't see that 😄
It wouldn't be a problem in luci (as it is with my depending PR openwrt/luci#8017), because it relies on : as separator.

Maybe 00-01-AA-00-00-00..00-01-AA-FF-FF-FF gives the right idea?
But I don't know if this is the best approach?
Maybe changing this adds an additional cognitive load to remember that ranges are noted with .. as range symbol in fw4.
I think - is more intuitive.

Additionally after parsing it transforms to 00:01:AA:00:00:00-00:01:AA:FF:FF:FF again in fw4.

brada4 · 2025-11-10T13:22:39Z

99% of users will supply valid values but we dont want others to break ruleset.

systemcrash · 2025-11-10T15:05:02Z

I think - is more intuitive.

Agreed. Just happier that we at least discussed the potential problem here.

ckorber · 2025-11-20T08:08:44Z

Don't want to push it, but there is no progress on this PR. Can someone review and merge it?
Or is it only possible by @jow-?

systemcrash · 2025-11-20T11:59:28Z

Any maintainer can.

systemcrash · 2025-11-21T14:59:26Z

@ckorber Recommend tweaking the commit message a bit to e.g.

So this is now possible:

option src_mac '00:11:AA:00:00:00-00:11:AA:FF:FF:FF'

In addition to the original:

option src_mac '00:11:AA:00:00:00'

ckorber · 2025-11-21T19:17:07Z

I added that. Thanks!

@ckorber Recommend tweaking the commit message a bit to e.g.

So this is now possible:
option src_mac '00:11:AA:00:00:00-00:11:AA:FF:FF:FF'
In addition to the original:
option src_mac '00:11:AA:00:00:00'

ckorber · 2025-11-26T10:20:34Z

@nbd168 or @stintel : Do one of you want to review, because you committed to the project in the past? @jow- seems to be unavailable for review.
Thanks in advance!

systemcrash · 2025-11-26T21:29:43Z

Hi @robimarko could we get this in for 25?

This commit is a preparation to add the possibility to block or accept a range of MAC addresses int they syntax of: ''' 00:11:22:00:00:00-00:11:22:ff:ff:ff ''' The commit depends on the PR openwrt/firewall4#74 being merged first. Signed-off-by: Christian Korber <[email protected]>

nft supports handling mac ranges and therefore this commit changes fw4 to support that feature. The src_mac is now allowed to be a range of two addresses. If no range is given, the old logic is applied. So this is now possible: ``` option src_mac '00:11:AA:00:00:00-00:11:AA:FF:FF:FF' ``` In addition to the original: ``` option src_mac '00:11:AA:00:00:00' ``` This is done by changing the regex to parse for an additional MAC address if '-' is matched after the first MAC address. Negative matching using exclamation mark is supported. Signed-off-by: Christian Korber <[email protected]>

ckorber · 2026-01-19T12:37:47Z

I updated the PR because as I tested it, it no longer supported inserting only one MAC.
Now this is possible again. I split the two cases into two regexes.

ckorber changed the title ~~firewall4: enable mac ranges for rule~~ fw4: enable mac ranges for rule Oct 2, 2025

ckorber force-pushed the pr/fw4_macrange branch from a8d2c34 to 9dfde8b Compare October 8, 2025 19:48

ckorber force-pushed the pr/fw4_macrange branch from 9dfde8b to 27ef07d Compare October 8, 2025 20:04

ckorber commented Oct 9, 2025

View reviewed changes

ckorber force-pushed the pr/fw4_macrange branch from 27ef07d to 52dfc8e Compare October 13, 2025 06:55

ckorber force-pushed the pr/fw4_macrange branch 2 times, most recently from d8b4117 to 2dd4c3e Compare October 14, 2025 08:22

ckorber force-pushed the pr/fw4_macrange branch from 2dd4c3e to 176bb6f Compare October 14, 2025 09:10

ckorber force-pushed the pr/fw4_macrange branch from 176bb6f to 177a3db Compare October 16, 2025 11:57

ckorber mentioned this pull request Oct 17, 2025

luci-base, luci-app-firewall: enable range of MAC addresses openwrt/luci#8017

Draft

7 tasks

ckorber force-pushed the pr/fw4_macrange branch from 177a3db to 625340b Compare October 31, 2025 11:45

ckorber force-pushed the pr/fw4_macrange branch from 625340b to 6eaa214 Compare November 10, 2025 11:45

ckorber force-pushed the pr/fw4_macrange branch from 6eaa214 to 50ed665 Compare November 21, 2025 19:15

ckorber force-pushed the pr/fw4_macrange branch from 50ed665 to cc792d4 Compare January 19, 2026 10:31

Conversation

ckorber commented Oct 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brada4 commented Oct 2, 2025

Uh oh!

ckorber commented Oct 7, 2025

Uh oh!

brada4 commented Oct 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ckorber commented Oct 7, 2025

Uh oh!

brada4 commented Oct 7, 2025

Uh oh!

brada4 commented Oct 8, 2025

Uh oh!

ckorber commented Oct 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

brada4 commented Oct 8, 2025

Uh oh!

brada4 commented Oct 8, 2025

Uh oh!

ckorber Oct 9, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ckorber Oct 13, 2025

Choose a reason for hiding this comment

Uh oh!

ckorber commented Oct 14, 2025

Uh oh!

brada4 commented Oct 14, 2025

Uh oh!

ckorber commented Oct 20, 2025

Uh oh!

systemcrash commented Oct 29, 2025

Uh oh!

ckorber commented Oct 31, 2025

Uh oh!

brada4 commented Oct 31, 2025

Uh oh!

ckorber commented Oct 31, 2025

Uh oh!

systemcrash commented Oct 31, 2025

Uh oh!

brada4 commented Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ckorber commented Nov 10, 2025

Uh oh!

systemcrash commented Nov 10, 2025

Uh oh!

brada4 commented Nov 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ckorber commented Nov 10, 2025

Uh oh!

brada4 commented Nov 10, 2025

Uh oh!

systemcrash commented Nov 10, 2025

Uh oh!

ckorber commented Nov 20, 2025

Uh oh!

systemcrash commented Nov 20, 2025

Uh oh!

systemcrash commented Nov 21, 2025

Uh oh!

ckorber commented Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ckorber commented Nov 26, 2025

Uh oh!

systemcrash commented Nov 26, 2025

Uh oh!

ckorber commented Jan 19, 2026

Uh oh!

Reviewers

Assignees

ckorber commented Oct 2, 2025 •

edited

Loading

brada4 commented Oct 7, 2025 •

edited

Loading

ckorber commented Oct 8, 2025 •

edited

Loading

ckorber Oct 9, 2025 •

edited

Loading

brada4 commented Oct 31, 2025 •

edited

Loading

brada4 commented Nov 10, 2025 •

edited

Loading

ckorber commented Nov 21, 2025 •

edited

Loading