I just tested in 1.3.5, and I’m getting the same error.

I finally got a chance to dive into this some more.

Upgraded to vyos-1.5-rolling-202312130023-amd64, and confirmed that it is encrypting.

tcpdump of internal MPLS interface during initial connection

Adding trace, and monitoring, shows that the rule is never being hit.

PR2518 submitted

It looks like maybe there’s just some op mode command changes.

I’m also seeing this error after the update to 1.3.4

Interestingly enough, I just found this error as well, but showed lines 173, 130, and 66.

Thanks for the follow-up @eyanulis!

@jworrell I agree that if an administrator turns on a service it should be functional. If no firewall is configured, and a security ruleset isn't required for the use case, there's no issue with something being in place that allows that traffic for extra comfort. However, if security rules are in place it should be the burden of the administrator to define how that management traffic should be handled. This would be consistent with previous versions of VyOS that if you applied a default-deny to the local direction of an interface, you would need to specify any management traffic for the interface explicitly. By introducing hidden allows, this would violate the principle of least surprise that you mentioned.

I would disagree with a hidden ruleset.

Pull request #2156 opened
https://github.com/vyos/vyos-1x/pull/2156

There are use cases when it would be ideal to force a password at boot to protect the contents of the configuration. For example, a portable router with sensitive keys meant for temporary network connectivity.

Can this be accomplished with LUKS?

In talking with the vendor, this appears to be an incompatibility with the WiFi card and the coreboot BIOS installed on the device. Tested with a second device that had a different card installed, and no such errors are present now.

VyOS 1.4-rolling-202306280317 show the following additional dmesg items

Tried the following:

echo 1 > /sys/bus/pci/devices/0000:03:00.0/remove
echo 1 > /sys/bus/pci/rescan

Attempted a modprobe -r ath10k_pci and the re-load the module. The following dmesg is what I saw after.

Rule used for udev testing:

I successfully tested a udev rule to rename to wwan0.

Tested successfully! Modem showed up as usb0 in ip link, but not in show interfaces.