[pkg-netfilter-team] Bug#959427: nftables: On boot "nftables.service" fails to start

[Arturo Borrero Gonzalez]

On 5/2/20 12:12 PM, Damir Koscic wrote:
> Package: nftables
> Version: 0.9.0-2
> Severity: important
> 
> Dear Maintainer,
> 
> On boot "nftables.service" fails to start. The excerpt from systemd journal
> (shown on bottom of mail), shows that offending part of of config file is:
> 
> 	table netdev macs{
> 		chain mac_filter{
> 			type filter hook ingress device ens192 priority 0; policy drop;
> 			ether saddr "00:0c:29:0b:04:09" accept
> 		}
> 	}
> 
> The config file itself is OK, since there is no problem starting "nftables"
> after boot procedure is done (boot procedure itself is not compromised as
> described in another bug report).
> 
> The fact, that nft error messages were nested between "systemd-udevd" messages,
> suggested that maybe "udevd" has not done its job entirely, and that somehow
> "nftables" depends on it. What I have tried to do is to add following into
> "nftables.service" unit file (using "systemctl edit", thus not modifying packa-
> ge original unit file):
> 
> 	After=systemd-udevd.service
> 
> That solved the problem, and all successive reboots were successful.
> 
> I hope this helps you identify the problem and find proper solution for it :)
> 
> Kind regards,
>   Damir Koscic
> 
> 
> Excerpt from systemd journal:
> ----------------------------------
>   audit[317]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined"
>   systemd-udevd[278]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
>   systemd-udevd[288]: Using default interface naming scheme 'v240'.
>   systemd-udevd[289]: Using default interface naming scheme 'v240'.
>   nft[244]: /etc/nftables.conf:61:11-27: Error: Could not process rule: No such file or directory
>   nft[244]:     chain mac_filter{
>   nft[244]:           ^^^^^^^^^^
>   nft[244]: /etc/nftables.conf:63:9-39: Error: Could not process rule: No such file or directory
>   nft[244]:         ether saddr "00:0c:29:0b:04:09" accept
>   nft[244]:         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>   systemd-udevd[278]: Using default interface naming scheme 'v240'.
>   systemd-udevd[290]: Using default interface naming scheme 'v240'.
>   systemd-udevd[288]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
>   systemd-udevd[289]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
>   systemd-udevd[278]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
>   systemd-udevd[290]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
>   systemd-udevd[283]: Using default interface naming scheme 'v240'.
>   systemd[1]: Starting Flush Journal to Persistent Storage...
> 
> -- System Information:
> Debian Release: 10.3
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
c
ould it be that the interface the chain is referring to is not available at the
time of loading the ruleset?

nftables has no way to bring up interfaces on its own, so yeah, you might have
an udev dependency on your particular configuration that you should configure in
your service file (like you did).

Anyway, I don't this there is an actionable here? The service file can be
configured to keep trying to start the ruleset until the operation is successful.

BTW, Did you try with a newer kernel? There is linux kernel from the v5 family
in buster-bpo.

I'm closing the bug report now, as I think this is more related to the
particular configuration of your system. Thanks for the report, and feel free to
reopen if required!