Regression #14410
open
Behavior of ``earlyshellcmd`` changed, ``ngeth`` interfaces cannot be initiated early enough to pass assignment check
0%
Description
In pfSense Plus 23.01, I was leveraging earlyshellcmd to create a virtual network interface & handle 802.1x authentication before pfSense checks whether reassignment of interfaces is required. While this specific use case has been recently solved in 23.05 through other officially supported ways, there's another issue at hand here.
For some background, I'm utilizing pfatt (as called out in the link above) to handle 802.1x auth with AT&T. After applying the update, pfSense was unable to boot due to not finding the ngeth0 interface that the pfatt script was tasked to create. This is because in 23.05, I have confirmed that the configured shell commands with the earlyshellcmd option are being executed later in the boot sequence than the previous release. More specifically, the /etc/rc.bootup PHP script was updated so that the early shell commands (which are called off by system_do_shell_commands(1)) are executed after the while (is_interface_mismatch() == true)... code block (which then halts the boot process if it fails). Previously to 23.05, system_do_shell_commands(1) was called before that aforementioned while loop, just like how pfSense CE functions today, which can be seen in the code here.
While my particular issue can be solved by the newly introduced auth bridging functionality, it still begs the question of whether the changed execution sequence of earlyshellcmd commands being impacted was intentional or not; from my standpoint, it's a regression as other pfSense Plus users may be relying on these early shell commands executing before the networking interfaces are checked.
Specifically to my use case, I'll switch over to the new way of configuring this authentication method soon, however, I wanted to file this issue so the pfSense Plus team is aware of this regression. Please let me know if you require any more insight into this problem.
Thanks!
Updated by
Updated by Christian McDonald 11 months ago
The reason for this change is due to how WireGuard tunnels are created via early shell commands and the new cryptographic accelerator (IIMB) that was introduced in 23.05. The reordering was done to push early shell commands down after loading crypto modules and setting sysctls so that the desired crypto is in place before creating WireGuard tunnels.
WireGuard is not impacted by this change because we append `tun_` to each WireGuard interface name which takes advantage of a check here [1] that ensures these interfaces are ignored when checking for the interface mismatch condition.
I will revisit this and see if we can restore the original behavior, and what that means for WireGuard utilizing the new IIMB crypto when enabled.
Updated by Taylor Jasko 11 months ago
Thanks for the quick response, Christian. That makes complete sense to me. This makes me wonder if it's possible to update the logic of the is_interface_mismatch() function to determine if the interface is physical or virtual, instead of mostly relying on regex matching based on that interface's name that's happening now; perhaps by using something like pciconf -lv would work. I'm sure that's likely a can of worms though...
I suppose the easier option is to introduce more options to these shell commands so that the execution order is a bit more customizable.
Will continue to follow this issue to see what you all decide on.
Updated by Steve Wheeler 11 months ago
Adding ngeth to the 'do not check' list doesn't seem like a bad option. That is always a virtual interface.
Updated by Hayden Hill 11 months ago
I'm also having this issue with the most recent upgrade. I switched to the new GUI supported 802.1x forwarding method temporarily (big thanks) but would prefer a solution that solved the ngeth0 interface assignment issue. Or if wpa_supplicant supports VLAN 0 than this issue would go away entirely.
Updated by Christian McDonald 11 months ago
I have now added ngeth interfaces to the list of ignored prefixes.
I will continue to investigate this regression.
Updated by Hayden Hill 11 months ago
Christian McDonald wrote in #note-6:
I have now added ngeth interfaces to the list of ignored prefixes.
I will continue to investigate this regression.
Thanks! Is there a patch we could use in the meantime?
Updated by Steve Wheeler 11 months ago
You should be able to add the commit via system patches:
https://github.com/pfsense/pfsense/commit/c13bf6d4d174d77768d9090e97b3379835495356
Updated by Hayden Hill 11 months ago
Steve Wheeler wrote in #note-8:
You should be able to add the commit via system patches:
https://github.com/pfsense/pfsense/commit/c13bf6d4d174d77768d9090e97b3379835495356
Thanks! No differences between CE and Plus?
Updated by Steve Wheeler 11 months ago
I tested it against 23.05. It's already in 2.7 snaps.
Updated by Taylor Jasko 11 months ago
I've been running on a similar patch as well & have had no issues on 23.05. I'm not surprised that Git commit also cleanly applies to Plus, as that particular part of the code is the same.
Updated by Hayden Hill 11 months ago
Thanks! Patch applied and running perfectly!
Updated by Jim Pingle 11 months ago
- Affected Plus Version deleted (
23.05) - Project changed from pfSense Plus to pfSense
- Subject changed from Behavior of ``earlyshellcmd`` changed in 23.05 to Behavior of ``earlyshellcmd`` changed, ``ngeth`` interfaces cannot be initiated early enough to pass assignment check
- Category changed from Operating System to Operating System
- Target version changed from 23.05.1 to 2.7.0
- Plus Target Version set to 23.05.1
Updated by Jim Pingle 10 months ago
- Target version changed from 2.7.0 to CE-Next
Updated by Jim Pingle 10 months ago
- Plus Target Version changed from 23.05.1 to 23.09
Updated by Jim Pingle 8 months ago
- Plus Target Version changed from 23.09 to 24.01
Updated by Jim Pingle 7 months ago
- Plus Target Version changed from 24.01 to 24.03
Updated by Jim Pingle about 2 months ago
- Plus Target Version changed from 24.03 to 24.07