Regression #14525
closed
PHP error in ``status_ipsec.php`` after removing active IPsec tunnel configuration
100%
Description
Stack trace:
#0 /usr/local/www/status_ipsec.php(345): array_key_first(NULL)
#1 /usr/local/www/status_ipsec.php(51): print_ipsec_body()
#2 {main}
thrown in /usr/local/www/status_ipsec.php on line 345
[29-Jun-2023 09:53:43 US/Central] PHP Fatal error: Uncaught TypeError: array_key_first(): Argument #1 ($array) must be of type array, null given in /usr/local/www/status_ipsec.php:345
A customer hit this on 23.05. I will attempt to reproduce it, but we should add a check for this situation either way.
Files
Updated by Craig Coonrad over 1 year ago
Another instance of this (v23.05):
#0 /usr/local/www/status_ipsec.php(345):array_key_first(NULL)
#1 /usr/local/www/status_ipsec.php(51): print _ipsec _body
#2 {main}
thrown @2023-08-07 18:04:25
• PHP ERROR: Type: 1, File: /usr/local/www/status _ipsec.php, Line: 345, Message:
Uncaught TypeError: array_key_first(: Argument #1 (Sarray) must be of type array,
Updated by Kris Phillips about 1 year ago
Do we know what reproduces this error?
Updated by Filip Bengtsson about 1 year ago
I began getting the same error by doing this:
I had an IPsec connection to a remote site already set up, but the remote site was getting a new ISP and would have both connections for a few days. So I created an IPsec tunnel to the new WAN interface (with two phase 2 entries) and made sure they worked before deleting the old one. At some point during this, I began getting this error every time I visit the dashboard on either the remote or local pfSense servers. Note that it affects both installations the same way.
Crash report begins. Anonymous machine information:
amd64
14.0-CURRENT
FreeBSD 14.0-CURRENT #1 RELENG_2_7_0-n255866-686c8d3c1f0: Wed Jun 28 04:21:19 UTC 2023 root@freebsd:/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/obj/amd64/LwYAddCr/var/jenkins/workspace/pfSense-CE-snapshots-2_7_0-main/sources/FreeBSD-src-REL
Crash report details:
PHP Errors:
[24-Sep-2023 02:15:25 Europe/Stockholm] PHP Fatal error: Uncaught TypeError: array_key_first(): Argument #1 ($array) must be of type array, null given in /usr/local/www/status_ipsec.php:345
Stack trace:
#0 /usr/local/www/status_ipsec.php(345): array_key_first(NULL)
#1 /usr/local/www/status_ipsec.php(51): print_ipsec_body()
#2 {main}
thrown in /usr/local/www/status_ipsec.php on line 345
No FreeBSD crash data found.
Updated by Jim Pingle about 1 year ago
- Subject changed from PHP error in status_ipsec.php to PHP error in ``status_ipsec.php``
- Assignee changed from Christopher Cope to Jim Pingle
- Target version set to 2.8.0
- Plus Target Version set to 23.09
- Tracker changed from Bug to Regression
Did the error go away if you stopped/started (not restart) the IPsec daemon?
For it to hit the error there, it would have to have a P1 in the connection state data, but no P2 SA, though I can't provoke that here yet. We can certainly at least try to avoid that error, though, but it would be nice to have an easy way to replicate it.
I'll try to re-create your scenario in a lab here to see what happens.
Updated by Filip Bengtsson about 1 year ago
As you suspected; starting and stopping did solve the issue (and restarting it did not). At least on the local router, I rebooted pfSense on the remote site as I would not be able to turn the daemon back on again (already done that mistake once or twice).
Updated by Jim Pingle about 1 year ago
Filip Bengtsson wrote in #note-5:
As you suspected; starting and stopping did solve the issue (and restarting it did not). At least on the local router, I rebooted pfSense on the remote site as I would not be able to turn the daemon back on again (already done that mistake once or twice).
OK, that tells me it may have something to do with some "stale" data in the running IPsec daemon from the old/removed tunnel. Hopefully that makes it easier to reproduce in the lab.
Thanks!
Updated by Jim Pingle about 1 year ago
- Status changed from New to In Progress
While I could not reproduce it yet, I checked in what should be a fix for it. I tested the fix on several lab systems including one with ~20 IPsec tunnels of varying types and connection states and it was solid there.
Updated by Jim Pingle about 1 year ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 100
Applied in changeset 202e3c1b7d3af019f03bf2545a7f31062f8e8e08.
Updated by Jim Pingle about 1 year ago
- Subject changed from PHP error in ``status_ipsec.php`` to PHP error in ``status_ipsec.php`` after removing active IPsec tunnel configuration
Updated by aleksei prokofiev about 1 year ago
I can reproduce this error with follow
1. S2S Ipsec
2. With working state, I delete P2 on one side and got this error in status page
3. Restart is not solve it, only stop/start service
Updated by aleksei prokofiev about 1 year ago
Tested patch on
2.7.0-RELEASE (amd64)
built on Wed Jun 28 03:53:34 UTC 2023
FreeBSD 14.0-CURRENT
Patch fixed this issue.
Updated by aleksei prokofiev about 1 year ago
Tetsed on
23.05.1-RELEASE (amd64)
built on Wed Jun 28 03:57:27 UTC 2023
FreeBSD 14.0-CURRENT
The patch working as well
Updated by Jim Pingle about 1 year ago
- Status changed from Feedback to Resolved
Updated by Jim Pingle about 1 year ago
- Target version changed from 2.8.0 to 2.7.1