fw4 assumes ether_addr sets are ipv4 only

[f00b4r0]

Given the following uci configuration:

    add firewall rule
    set firewall.@rule[-1].name='Forward-auth-captive'
    set firewall.@rule[-1].src="captivezone"
    set firewall.@rule[-1].dest='wan'
    set firewall.@rule[-1].proto='any'
    set firewall.@rule[-1].target='ACCEPT'
    set firewall.@rule[-1].ipset='captive'

    add firewall ipset
    set firewall.@ipset[-1].name='captive'
    add_list firewall.@ipset[-1].match='src_mac'

firewall4 produces the following rules:

table inet fw4 {
    set captive {
        type ether_addr
        elements = { }
        }

[...]

    chain forward_captivezone {
        meta nfproto ipv4 ether saddr @captive counter packets 111598 bytes 30867442 jump accept_to_wan comment "!fw4: Forward-auth-captive"

The meta nfproto ipv4 match is unwarranted as the relative set is address agnostic.

[brada4]

To emit expected rule - change:

first line of /usr/share/firewall4/templates/rule.uc
-{%+ if (rule.family && !rule.has_addrs): -%}
+{%+ if (rule.family && !rule.has_addrs && length(rule.smacs_pos)!=null ): -%}

@jow- may explain why plain !rule.smacs_pos does not work in this line but works perfectly 30 lines later. this may spread more where lenght() of an dynamic array is numeric zero vs null same treatment has to be applied to nftporto agnostic smacs_neg and maybe port list.

[brada4]

@f00b4r0 any success editing file?

[f00b4r0]

@brada4 afaict the change does work, the rule is changed to:

    chain forward_captive {
        ether saddr @captive counter packets 14 bytes 1652 jump accept_to_wan comment "!fw4: Forward-auth-captive"

However I can't say for sure whether or not this breaks anything else.

[brada4]

It does not break anything else, just removes proto specifier in exact reported case. I will make PR out of this, not dwelling into other similar situations I grepped. EDIT: my easy idea breaks rules with multiple filters