pfSense

The error is a bit odd considering the code there:

[07-Nov-2023 22:12:51 Europe/London] PHP Fatal error:  Uncaught TypeError: Illegal offset type in /usr/local/www/interfaces.php:1996
Stack trace:
#0 {main}
  thrown in /usr/local/www/interfaces.php on line 1996

Lines 1995-1998 on 23.09 should be:

if (!in_array(array_get_path($pconfig, 'type'), ["ppp", "pppoe", "pptp", "l2tp"]) ||
   !array_key_exists(array_get_path($a_ppps, "{$pppid}/ports", []), get_configured_interface_list_by_realif())) {
    $types4 = array_merge(["none" => gettext("None"), "staticv4" => gettext("Static IPv4"), "dhcp" => gettext("DHCP")], $types4);
}

There isn't anything on those lines using an array index/offset that would lead to that PHP error.

Does this system have any custom system patches applied/reverted or anything else similar going on?

If you open /usr/local/www/interfaces.php and look at line 1996 in that file, what is there?

I can replicate this in 23.09 after setting an interface IPv4 type from none to pppoe:

--- /conf/backup/config-1698885352.xml    2023-11-08 18:13:21.122207000 +0000
+++ /conf/config.xml    2023-11-08 18:13:21.156187000 +0000
@@ -146,8 +146,10 @@
         </opt1>
         <opt2>
             <enable></enable>
-            <if>ix1</if>
+            <if>pppoe0</if>
             <descr><![CDATA[OPT2]]></descr>
+            <ipaddr>pppoe</ipaddr>
+            <spoofmac></spoofmac>
         </opt2>
         <opt3>
             <descr><![CDATA[OPT3]]></descr>
@@ -26572,9 +26574,9 @@
         </lagg>
     </laggs>
     <revision>
-        <time>1698885352</time>
-        <description><![CDATA[(system): [pfSense-pkg-WireGuard] Applied package default settings as necessary.]]></description>
-        <username><![CDATA[(system)]]></username>
+        <time>1699467201</time>
+        <description><![CDATA[admin@172.21.16.8 (Local Database): Interfaces settings changed]]></description>
+        <username><![CDATA[admin@172.21.16.8 (Local Database)]]></username>
     </revision>
     <gateways>
         <defaultgw4>WAN_DHCP</defaultgw4>

It appears there are multiple problems here.

This line is failing because it's falling through to the default case but the parameter can't be an array, so the default case is wrong:

!array_key_exists(array_get_path($a_ppps, "{$pppid}/ports", []), get_configured_interface_list_by_realif())) {

However it's not as simple as fixing the default case because a PPP entry could have multiple selected ports so "{$pppid}/ports" could contain a value such as "vtnet2,vtnet3" which could never work for the kind of test this is attempting.

So it may need changed to something closer to this:

!array_intersect_key(explode(",", array_get_path($a_ppps, "{$pppid}/ports", "")), get_configured_interface_list_by_realif())) {

There are indeed two separate issues here, one that affects CE and Plus and one that is Plus only

The issue affecting both is the PHP error, which happens when there are no PPP config values to store which leads to an input validation error on CE but has a different root cause on Plus.

The issue affecting Plus is that the PPP config and gateway config are not storing their values properly which means that while fixing the PHP error allows the user to save the page without a visible error, the PPP configuration isn't stored so it cannot be used.

Attached are two patches:

1. 5eb325e0def04241684b4d2c9583f8ca9d8bc05e.patch -- Should be applied only to Plus 23.09 to address the root cause of the problem there
2. 345ede29dbfad4afdf6b1d7afd73213158b41cce.patch -- Should be applied to CE 2.7.1 and Plus 23.09 to address the PHP error

You can install the System Patches package and then create an entry for each of these patches to apply the fix. These will be added to the system patches package in the near future.

As a workaround instead of applying patches, users can create a PPP entry under Interfaces > Assignments on the PPPs tab and then select that for assignment on Interfaces > Assignments. After that, edit the interface and enable it, then save/apply.

Jim Pingle wrote in #note-19:

Not sure why they are rejected for you when uploading the file, but if you open them in a text editor that supports unix line endings you can just copy/paste the text of the patch(es) into patch entries and they work that way.

I followed Jim's instructions and the patches did the job.

I am marking this case resolved.