Regression #14410
closedBehavior 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!