Project

General

Profile

Actions

Regression #14410

open

Behavior of ``earlyshellcmd`` changed, ``ngeth`` interfaces cannot be initiated early enough to pass assignment check

Added by Taylor Jasko about 1 year ago. Updated 3 months ago.

Status:
New
Priority:
Normal
Category:
Operating System
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
24.07
Release Notes:
Default
Affected Version:
Affected Architecture:
All

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!

Actions #1

Updated by Marcos M about 1 year ago

  • Assignee set to Christian McDonald
Actions #2

Updated by Christian McDonald about 1 year 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.

[1] https://github.com/pfsense/pfsense/blob/217f42ec30a4008907ac6fbb65b7b2e0ebf51eb9/src/etc/inc/util.inc#LL2477C20-L2477C129

Actions #3

Updated by Taylor Jasko about 1 year 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.

Actions #4

Updated by Steve Wheeler about 1 year ago

Adding ngeth to the 'do not check' list doesn't seem like a bad option. That is always a virtual interface.

Actions #5

Updated by Hayden Hill almost 1 year 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.

Actions #6

Updated by Christian McDonald 12 months ago

I have now added ngeth interfaces to the list of ignored prefixes.

I will continue to investigate this regression.

Actions #7

Updated by Hayden Hill 12 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?

Actions #8

Updated by Steve Wheeler 12 months ago

You should be able to add the commit via system patches:
https://github.com/pfsense/pfsense/commit/c13bf6d4d174d77768d9090e97b3379835495356

Actions #9

Updated by Hayden Hill 12 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?

Actions #10

Updated by Steve Wheeler 12 months ago

I tested it against 23.05. It's already in 2.7 snaps.

Actions #11

Updated by Taylor Jasko 12 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.

Actions #12

Updated by Hayden Hill 12 months ago

Thanks! Patch applied and running perfectly!

Actions #13

Updated by Jim Pingle 12 months ago

  • Target version set to 23.05.1
Actions #14

Updated by Jim Pingle 12 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
Actions #15

Updated by Jim Pingle 11 months ago

  • Target version changed from 2.7.0 to CE-Next
Actions #16

Updated by Jim Pingle 11 months ago

  • Plus Target Version changed from 23.05.1 to 23.09
Actions #17

Updated by Jim Pingle 9 months ago

  • Plus Target Version changed from 23.09 to 24.01
Actions #18

Updated by Jim Pingle 8 months ago

  • Plus Target Version changed from 24.01 to 24.03
Actions #19

Updated by Jim Pingle 3 months ago

  • Plus Target Version changed from 24.03 to 24.07
Actions

Also available in: Atom PDF