Errors that occurred during upgrades to 23.01 and 23.05 RC
-
I've been trying to figure out why my GUI log is being flooded after my recent update to 23.01 (and remains after trying upgrading 23.05 RC). In going through the upgrade_log.latest.txt file I found the following issues were reported...
[99/157] Extracting php82-pear-Net_Socket-1.2.2: ....... done
Followed by:
Warning: foreach() argument must be of type array|object, null given in Command.php on line 249
<repeats>
Warning: Trying to access array offset on value of type null in Role.php on line 250
Warning: Trying to access array offset on value of type null in Role.php on line 251
<repeats>
Warning: Undefined array key "honorsbaseinstall" in Role.php on line 173
<repeats>
Warning: Undefined array key "installable" in Role.php on line 139
<repeats>
Warning: Undefined array key "phpfile" in Role.php on line 204
<repeats>
Warning: Undefined array key "config_vars" in Role.php on line 46
<repeats>
XML Extension not found
pkg-static: POST-INSTALL script failed
…
[101/157] Extracting php82-pear-Net_URL2-2.2.1: .......... done
Same as above
[109/157] Extracting php82-pear-Cache_Lite-1.8.3,1: .......... done
Same as above
[110/157] Extracting php82-pear-Net_SMTP-1.10.1: .......... done
Same as above
[114/157] Extracting php82-pear-HTTP_Request2-2.5.1,1: .......... done
Same as above
[116/157] Extracting php82-pear-Crypt_CHAP-1.5.0_2: ... done
Same as above
[128/157] Extracting php82-pear-XML_RPC2-1.1.5: .......... done
Same as above
[135/157] Extracting php82-pear-Net_IPv6-1.3.0.b4_2: ...... done
Same as above
[144/157] Extracting php82-pear-Mail-1.4.1,1: .......... done
Same as above
[149/157] Extracting php82-pear-Auth_RADIUS-1.1.0_4: ....... done
Same as aboveI can’t claim to understand the issue, but in trying to hunt down a solution, what I found was (and I don’t know if its relevant, but providing in case it is) was this:
[https://serverfault.com/questions/589877/pecl-command-produces-long-list-of-errors](link url)with the following info:
“Finally after some further research and reviewing the source code for PECL/PEAR I found the real cause. Hopefully what follows will be of help to others:You may see this error when trying to run PECL if your PHP installation does not have XML enabled by default, but instead XML support is usually loaded into your PHP installation via a PHP extension module (this could occur if the
./configure --disable-xmlflag was specified when building PHP from source, or if you installed PHP via various package managers where that build of PHP is configured to load XML via an extension module).Notice how the last line of the error output from PECL is
XML Extension not found– the reason this error is appearing is because when PECL tries to use its XMLParser.php class it fails because it cannot access the XML extension (it checks for the XML module usingextension_loaded('xml')around line 259 of the XMLParser.php source), and because the XML module is unavailable, it cannot parse its configuration/settings files and outputs all of the other errors seen above.The reason this issue occurs is due to the way that PECL operates. The PECL command itself is just a shell script, which first works out where PHP is installed on your system installation, and then calls PHP on the command line with a number of flags before providing the path to the main PECL PHP script file. The problem flag which the PECL shell script is using is the
-noption, which tells PHP to ignore anyphp.inifiles (and therefore PHP will not load any of the additional extensions yourphp.inifile specifies, including in this case XML).One can see the impact of the
-nflag by running the following two commands:
first try runningphp -mon the command line
then compare the output tophp -n -m
You should not see the XML extension listed when you run the second command because the-nflag told PHP not to parse ourphp.inifile(s).If you run
vi `which pecl`on the command line you should see the contents of the PECL command (as noted above, its just a shell script), and if you inspect the last line, you will see something like this:exec $PHP -C -n -q $INCARG -d date.timezone=UTC -d output_buffering=1 -d variables_order=EGPCS -d safe_mode=0 -d register_argc_argv="On" $INCDIR/peclcmd.php "$@"You should see the
-nflag listed between the-Cand-qflags. If you edit the PECL shell script, omitting the-nflag you should now be able to run PECL again without issues.Alternatively, you can recompile PHP from source making sure that the XML module is compiled into the PHP binary instead of being loaded from a PHP extension module at run-time. Obviously editing the PECL shell script to remove the
-nflag will only fix the issue until PECL/PEAR gets re-installed, hopefully however the maintainers of PECL/PEAR can update their repo with this fix. Ensuring PHP is built with XML support compiled in, is however a long-term fix to the solution, but may not be ideal for everyone's circumstances.Just for completeness, if you run
vi `which pear`you will see a very similar shell script to the one that PECL uses, however the-nflag is missing from the command which calls PHP and as such the PEAR command is not subject to these same issues"Again, I am not claiming anything as to what might or might not resolve this, etc. just including it in the hope that it might point folks in a useful direction if this is a larger problem that needs to be addressed.
Thanks
-
All, of those errors are expected during the upgrade because of the php version change.
What errors are you actually seeing after the upgrade?
-
So before turning off logging the GUI errors into the system log, the system log was getting flooded with this one abnormal line:
May 8 19:14:28 pfSense nginx: 2023/05/08 19:14:28 [error] 92632#100298: *9036 open() "/usr/local/www/ubus" failed (2: No such file or directory), client: x.x.x.x, server: , request: "POST /ubus HTTP/1.1", host: "y.y.y.y."x.x.x.x = recently built new desktop ipv4 address that I typically use to log into pfsense
y.y.y.y = pfsense internal ipv4 addressHere is the most recent nginx log with addresses replaced:
Some of the info in the log may not be errors, but their frequency has me wondering about constant write activity. The one line in particular that does look to be an error is:
May 12 21:24:41 pfSense nginx: <internal pfs ipv4>52 - - [12/May/2023:21:24:41 -0400] "POST /ubus HTTP/1.1" 404 146 "-" "-"Thanks!
-
@sorjal That is that local device requesting /ubus from the web server. Is there a probe or scanner running on it? Quick search, looks openwrt related?
https://duckduckgo.com/?q=http+%2Fubus&t=iphone&anon_safari_group=9&ia=webOptions are to get it to stop, or block its IP by firewall rule to This Firewall port 80/443.
-
What could be generating those requests or how can I figure this out? The only new pieces of software that are on this system after upgrading the hardware and migrating everything using Laplink's PCMover are:
Laplink's PCMover
Gigabyte Control Center
Lian Li L-Connect 3
MSI Afterburner (direct from MSI site, not 3rd party)
Riva Tuner Statistics Server (goes with Afterburner)
Intel's Killer Network SuiteI also recently replaced the WiFi router (in AP mode) with a TP-Link Archer AXE300 from an Orbi mesh system that was being temperamental with smart outlets and apple's homekit. It's possible that this might be related because I hadn't checked the logs until recently and they only go back a few days given the turnover.
(in case this isn't obvious, this is home network)
Thanks
-
@sorjal Nothing openwrt related? Is the Pc Windows? Log out and if it stops, it’s running as the user (as opposed to background service).
-
Did something else have the pfSense LAN address previously? If it was some other router it might have been running Openwrt even if it wasn't obvious. Something appears to be trying to query it.
-
Nothing that I'm aware of is openwrt related, but who knows what the developers may be using. With that pc hibernating, I logged in from a macbook to check the nginx log and see what showed up. I found one line at 4am from another local pc (I haven't woken things up to confirm which, likely my wife's desktop). Then it's a lot of various lines with the client ip address of the macbook.
I've attached a txt copy of this portion of the log from the errors around the time I shutdown the desktop to recent.
-
So far I've gotten rid of:
Laplink's PCMover - no change
Riva Statistics Server - no changeI then used netstat -ab and netstat -aon in different command prompt windows and ended up witnessing a very large number of ports in the 95xxx range waiting with a process ID of 0. As I haven't a clue on how to determine what process might be opening these without a PID being displayed (I'm a home user and slowly teaching myself) I went with the next uninstall and removed the Killer Intelligence software and UWD installs as that does offer things like monitoring wifi channels, etc. After rebooting, I haven't seen that POST /ubus HTTP/1.1 line in the past 10 minutes, so something in there appears to be the cause.
Now I have to wonder was it generating that because I have some bad or missing configuration information, something in the Killer Suite software that needs to be configured (it was pretty devoid of actual configuration options other than turning features on and off) or is there a problem in that software itself that is generating those requests.
For now, I'm planning on leaving it along for a while to give it more time to see if the problem returns before changing anything else. Hopefully something in here is helpful to someone else, and I'll poke around later to see what else I can find.
Thanks!
-
Is your pfSense internal interface using 192.168.1.1? It's a very common address for routers and very likely this is just something trying to query a default address.
The Killer Suite looks to have all sorts of functionality, could well be that. I've never used it.
-
@stephenw10 Actually no, its in the 10.x.x.x range. While I do try and stay within what you're supposed to use for home network IP ranges, I try to switch away from 192.x.x.x often as it sometimes reveals when other devices aren't being configured properly, some internal configuration, etc. but it also reveals little bits here and there to learn about (such as not being to access some cable modems without being in that subnet, etc.). Again I tend to poke around to try and learn more about things casually which may point me to topics I want to learn more about.
-
@Sorjal said in Errors that occurred during upgrades to 23.01 and 23.05 RC:
I try to switch away from 192.x.x.x
A good idea in most cases.
