Bug #14949
closedPHP Error on ``interfaces.php`` when creating a PPP interface
Added by Jonny M 9 months ago. Updated 9 months ago.
100%
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
PHP_errors.log (820 Bytes) PHP_errors.log | Jonny M, 11/07/2023 10:18 PM | ||
345ede29dbfad4afdf6b1d7afd73213158b41cce.patch (1.01 KB) 345ede29dbfad4afdf6b1d7afd73213158b41cce.patch | Jim Pingle, 11/09/2023 05:04 PM | ||
5eb325e0def04241684b4d2c9583f8ca9d8bc05e.patch (1.08 KB) 5eb325e0def04241684b4d2c9583f8ca9d8bc05e.patch | Jim Pingle, 11/09/2023 05:04 PM |
Related issues
Updated by Jim Pingle 9 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?
Updated by Jonny M 9 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.
Updated by Jim Pingle 9 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.
Updated by Jonny M 9 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>
Updated by Jim Pingle 9 months ago
Was OPT1 configured before you started? Or was it freshly assigned?
Updated by Bob Dig 9 months ago
I also noticed this problem, although I hadn't used PPPoE for a while now.
https://forum.netgate.com/topic/183934/fatal-error-uncaught-typeerror-when-changing-second-wan-from-static-ip-to-pppoe/2?_=1699466386218
Updated by Steve Wheeler 9 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>
Updated by Jim Pingle 9 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())) {
Updated by Jim Pingle 9 months ago
- File 5eb325e0def04241684b4d2c9583f8ca9d8bc05e.patch 5eb325e0def04241684b4d2c9583f8ca9d8bc05e.patch added
- File 345ede29dbfad4afdf6b1d7afd73213158b41cce.patch 345ede29dbfad4afdf6b1d7afd73213158b41cce.patch added
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
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.
Updated by Jim Pingle 9 months ago
- Subject changed from interfaces.php Uncaught TypeError to PHP Error on ``interfaces.php`` when creating a PPP interface
Updated by Sean McBride 9 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...
Updated by Peter Kubik 9 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
Updated by Steve Wheeler 9 months ago
Works as expected in 23.09 here. Just use the 'Patch file upload' when you add the new patch.
Updated by Jim Pingle 9 months ago
- Has duplicate Bug #14969: PHP error after changing IPv4 Configuration Type from None to PPPoE added
Updated by Sean McBride 9 months ago
For me the patches were rejected also because they were "not in unified diff format".
How to proceed?
Updated by Jim Pingle 9 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.
Updated by Sean McBride 9 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)
Updated by Danilo Zrenjanin 9 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.
Updated by Jim Pingle 9 months ago
- Target version changed from 2.8.0 to 2.7.2
- Plus Target Version changed from 24.03 to 23.09.1
Updated by Jim Pingle 8 months ago
- Has duplicate Bug #15077: Uncaught TypeError: Illegal offset type in /usr/local/www/interfaces.php:1996 added