Project

General

Profile

Actions

Bug #14949

closed

PHP Error on ``interfaces.php`` when creating a PPP interface

Added by Jonny M 8 months ago. Updated 7 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Interfaces
Target version:
Start date:
Due date:
% Done:

100%

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

Description

I believe this may be related to #14790, it looks like that issue closed when nobody could make interfaces.php break any more. I can break it every time when configuring a PPPoE interface on OPT1 on an SG3100 running 23.09.

Crash report attached, please let me know what else you want off this system. The device was configured by installing the 23.01 recovery image onto the 3100, upgrading to 23.05.1, resetting to defaults, and then building a basic config with DHCP WAN. PPPoE had not been configured on this system until I attempted it and received this error.


Files


Related issues

Has duplicate Bug #14969: PHP error after changing IPv4 Configuration Type from None to PPPoEDuplicate

Actions
Has duplicate Bug #15077: Uncaught TypeError: Illegal offset type in /usr/local/www/interfaces.php:1996Duplicate

Actions
Actions #1

Updated by Jim Pingle 8 months ago

  • Status changed from New to Feedback

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?

Actions #2

Updated by Jonny M 8 months ago

Lines 1995-1998 are:

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);
}

Nothing custom is installed that I know about, and the only packages are aws-wizard and ipsec-profile-wizard which came with the system.

Actions #3

Updated by Jim Pingle 8 months ago

OK, two more questions:

1. What are the exact steps you are taking that produce the PHP error? I know you said "configuring PPPoE" but is this a new interface, changing an existing interface, or some other scenario? Having all the steps noted out will help us reproduce it in lab conditions.

2. Look inside /conf/config.xml or a current backup and see what is in the <ppps> ... </ppps> section. Post the whole section here, but remove/obscure any usernames/passwords.

Actions #4

Updated by Jonny M 8 months ago

I browse to Interfaces -> OPT1, change the IPv4 configuration to PPPoE, enter a PPPoE username and password, and then click Save. This redirects me to a white page with the PHP error on, and I cannot browse back to the OPT1 settings until I use SSH to reset the IP address of the interface to DHCP.

The config.xml contains <ppps></ppps> and no sign of my PPPoE user or credentials.

In case it's relevant, OPT1 is showing in the UI as mvneta0 but config.xml after I set it back to DHCP is:

<opt1>
                        <if>pppoe0</if>
                        <descr><![CDATA[OPT1]]></descr>
                        <spoofmac></spoofmac>
                        <alias-address></alias-address>
                        <alias-subnet>32</alias-subnet>
                        <enable></enable>
                        <ipaddr>dhcp</ipaddr>
                        <subnet></subnet>
                        <gateway></gateway>
                        <ipaddrv6></ipaddrv6>
                        <subnetv6></subnetv6>
                        <gatewayv6></gatewayv6>
                </opt1>

Actions #5

Updated by Jim Pingle 8 months ago

Was OPT1 configured before you started? Or was it freshly assigned?

Actions #6

Updated by Jonny M 8 months ago

Freshly assigned, I had not used that interface before I went to set PPPoE up on it for a second ISP.

Actions #8

Updated by Steve Wheeler 8 months ago

  • Status changed from Feedback to Confirmed
  • Affected Architecture All added
  • Affected Architecture deleted (SG-3100)

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>

Actions #9

Updated by Jim Pingle 8 months ago

  • Project changed from pfSense Plus to pfSense
  • Category changed from Interfaces to Interfaces
  • Target version set to 2.8.0
  • Affected Plus Version deleted (23.09)
  • Plus Target Version set to 24.03

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())) {
Actions #10

Updated by Jim Pingle 8 months ago

  • Assignee set to Jim Pingle
Actions #11

Updated by Jim Pingle 8 months ago

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.

Actions #12

Updated by Jonny M 8 months ago

Thanks for the speed of delivering the patch, I can confirm that I used the workaround method when it was mentioned in the forum post linked a few comments back and that worked fine, so I can wait until the next release for the fix.

Actions #13

Updated by Jim Pingle 8 months ago

  • Subject changed from interfaces.php Uncaught TypeError to PHP Error on ``interfaces.php`` when creating a PPP interface
Actions #14

Updated by Sean McBride 8 months ago

Crazy timing, but I only today tried to update from 23.05 to 23.09. When I go to Interfaces > WAN I reproducibly get this crash. My WAN connection is PPPoE (for vDSL). I switched boot environment back to previous system and now it works. I'll give those patches a try...

Actions #15

Updated by Peter Kubik 8 months ago

Jim, downloaded .patch files ... but when trying to upload to netgate pfsense I get The uploaded file must be in unified diff format. message.

Any advice, please ? Thanks

Actions #16

Updated by Steve Wheeler 8 months ago

Works as expected in 23.09 here. Just use the 'Patch file upload' when you add the new patch.

Actions #17

Updated by Jim Pingle 8 months ago

  • Has duplicate Bug #14969: PHP error after changing IPv4 Configuration Type from None to PPPoE added
Actions #18

Updated by Sean McBride 8 months ago

For me the patches were rejected also because they were "not in unified diff format".

How to proceed?

Actions #19

Updated by Jim Pingle 7 months ago

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.

Actions #20

Updated by Sean McBride 7 months ago

The files already have unix line endings and are UTF-8. I believe they are unaltered since download:

$ shasum -a 256 ~/Desktop/345ede29dbfad4afdf6b1d7afd73213158b41cce.patch ~/Desktop/5eb325e0def04241684b4d2c9583f8ca9d8bc05e.patch

803afab6d8fdd55e5bf4dac8b9a47b4beac875471fac988e5b5b2b0cfd202ac2 ~/Desktop/345ede29dbfad4afdf6b1d7afd73213158b41cce.patch
315194de5191c4dc289b045acf08eb6a73dbc6486b767500249306ff314cfdd8 ~/Desktop/5eb325e0def04241684b4d2c9583f8ca9d8bc05e.patch

I guess there must be some other bug here then. I'll try the copy-paste.

(Each test is a pain though, because every pfsense upgrade loses my PPPoE user & password, and since the WAN page is inaccessible I can't add it, which means I have no internet)

Actions #21

Updated by Danilo Zrenjanin 7 months ago

  • Status changed from Feedback to Resolved

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.

Actions #22

Updated by Jim Pingle 7 months ago

  • Target version changed from 2.8.0 to 2.7.2
  • Plus Target Version changed from 24.03 to 23.09.1
Actions #23

Updated by Jim Pingle 7 months ago

  • Has duplicate Bug #15077: Uncaught TypeError: Illegal offset type in /usr/local/www/interfaces.php:1996 added
Actions

Also available in: Atom PDF