PHP Fatal error : Cannot access offset of type string on string /usr/local/www/status_interfaces.php:137
-
@stephenw10 I have the exact same thing on my 2100 (my post). Realized later I was not first or the only one.
And to answer your question, no. No exotic config, just a set of interfaces that make up my network. No changes to any rules. Switch is in Port mode, nothing special.
-
-
@stephenw10 Switch configuration is the default and my interfaces config is normal, im using advanced settings for DHCPv4 and DHCPv6 but it shouldn't break anything.
@furom I also have a SG-1100 appliance with the same configuration and the issue doesn't show. Thats weird. What kind of filesystem are you using ? UFS or ZFS ?
I created a ticket on the netgate support, they said its likely due to a corrupt or incomplete update and then they sent a firmware to reinstall. I will do it and keep you informed if it works.
-
@superpaul209 said in PHP Fatal error : Cannot access offset of type string on string /usr/local/www/status_interfaces.php:137:
I created a ticket on the netgate support, they said its likely due to a corrupt or incomplete update and then they sent a firmware to reinstall. I will do it and keep you informed if it works.
Thanks! I was about to yesterday but awaited a response to posts first. I have for now reverted to 22.05 just in case as several different PHP issues seems to be happening. I do use ZFS
-
I opened a bug to track it: https://redmine.pfsense.org/issues/13981
Most of the php errors of this type are triggered in php8.1 because there is some value that in unset that php7 didn't care about. So I would be looking in the config for something in switch/vlan/interfaces that isn't present. But ultimately the page coding should be able to cope with that.
Steve
-
@stephenw10 Thanks, well, a lot of ppl seem to have upgraded successfully so assume I just had a bit of different luck this time... :) I really am a bit hesitant if I should spend the time trying to reflash, I just heard from another user who tried that it didn't fix the issue... I hope TAC is collecting enough info to be able to figure this one out. Any other device, but a firewall with scripting issues... I'll stick to what I believe works for now
-
I personally think it's more likely to be something uniquely missing in your config and a reinstall would still hit it given that same config. Should be pretty clear to our devs when they look into it.
Steve
-
@stephenw10 said in PHP Fatal error : Cannot access offset of type string on string /usr/local/www/status_interfaces.php:137:
I personally think it's more likely to be something uniquely missing in your config and a reinstall would still hit it given that same config. Should be pretty clear to our devs when they look into it.
Steve
Well, I don't dispute that, but it has worked flawless up until now, so a bit surprised. The support file is huge... Which parts should I look through before sending? Don't really like sending this kind of stuff over open internet. They should have a place to upload stuff really...
-
Indeed, never put the status output file up publicly.
Yeah php7 is far more tolerant. php8.1 in 23.01 enforces the rule strictly and will error out on missing values.
You shouldn't need to do anything here. Wait until our devs have reviewed it.
Steve
-
@stephenw10 Well.. TAC is not very nice today. They just plain closed the ticket after I uploaded the support file - without the slightest comment even. I have always been proud of using pfSense, but this I don't understand. Sure, it is TAC-Lite, but for failed upgrades that should still be ok, no?
-
You can upload it here and I'll make sure the devs see it if they need it:
https://nc.netgate.com/nextcloud/s/R896XCdBjKJtsqx -
@stephenw10 said in PHP Fatal error : Cannot access offset of type string on string /usr/local/www/status_interfaces.php:137:
You can upload it here and I'll make sure the devs see it if they need it:
https://nc.netgate.com/nextcloud/s/R896XCdBjKJtsqxThanks, but I did upload it already. The sad part of it is I flashed my unit with 23.01 and it went belly up again, same thing as before
so reverted back to 22.05and when I tried restoring one of the autobackup-configs, it gave me an error of it being too small and useless which felt a little strange as well, but another thread perhaps. Which of course reminded me of not just activating stuff, especially not backups - without also testing restore...
If there will be no patch release, I guess I will give it another try some day, but for now I've had it really. My config is not exotic in any way, no reason at all it should not just work (in my mind at least). If this through productive discussions can be proven not to be true I'd happily redesign, but think I have one or two things right at least.Edit: I mixed it up a bit above last night (was way too late and much too tired). Restore of autobackups was not possible for me on 23.01 after flashing the image. I configured it with the backupID from 22.05, thus had access and could list them. This ID was overwritten on reboot with a new one generated when installing 23.01 though... Are backups perhaps incompatible if they are created on 22.05?
Had I just not relied on this alone things would perhaps have gone a little smoother.Edit2: So this raises an interesting question. Will I have to debug this myself? From my perspective this seems to be a corner-case only happening to select few, cased by PHP being a lot more strict than before - but still something that should be handled in code, not by forcing re-design of users setup(s). This could have been a fun challenge if I had another firewall to use temporarily, but this is what I have. Having to mess with it like this makes it hard and also somewhat frustrating.
-
You have the ticket number so I can review it?
-
Ok, this is a bug. It shouldn't happen.
But it looks like you're hitting it because your switch config contains<vlangroups></vlangroups>
tags without any groups in even though it's in PORT vlan mode.Try removing that line from the swicth config section.
Steve
-
@stephenw10 said in PHP Fatal error : Cannot access offset of type string on string /usr/local/www/status_interfaces.php:137:
Ok, this is a bug. It shouldn't happen.
But it looks like you're hitting it because your switch config contains<vlangroups></vlangroups>
tags without any groups in even though it's in PORT vlan mode.Try removing that line from the swicth config section.
Steve
This is interesting! Where would I find that please? I have looked in 'Interfaces / Switch / VLANs' but see no tag. Is this what you refer to?
-
It's in the config file in /cf/conf/config.xml:
<switches> <switch> <device>/dev/etherswitch0</device> <vlanmode>PORT</vlanmode> ==> <vlangroups></vlangroups> <swports> <swport> <port>1</port> <state><![CDATA[forwarding]]></state> </swport>
Removing that line and rebooting should be sufficient.
-
@stephenw10 Thanks! Will try that asap. When trying just now I realized that sudo was missing so went into packages to verify and - none of my packages are there. In fact, no packages are available for install either... Sorry for the hassle, am a bit eager to try 23.01 again after this...
The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg from pkg+https://repo.netgate.com/pkg/pfSense_plus-v23_01_aarch64-pfSense_plus_v23_01, please wait... Could not load client key /etc/thoth/key.pem Could not load client key /etc/thoth/key.pem Could not load client key /etc/thoth/key.pem Could not load client key /etc/thoth/key.pem Could not load client key /etc/thoth/key.pem Could not load client key /etc/thoth/key.pem pkg: Error fetching https://repo.netgate.com/pkg/pfSense_plus-v23_01_aarch64-pfSense_plus_v23_01/Latest/pkg.txz: Authentication error A pre-built version of pkg could not be found for your system. Consider changing PACKAGESITE or installing it from ports: 'ports-mgmt/pkg'.
It seems it tries to get packages for 23.01 even though I am on 22.05 now... Uh.. What should I do, really? Fix this before flashing or ?
-
Upgrades for aarch64 (1100 and 2100) are disabled temporarily whist we fix the upgrade bug hitting systems with older installs. https://redmine.pfsense.org/issues/13967
Should be back soon. We have a good handle on what's happening there now.
So if you want to test that now you can install 23.01 clean and import the config with that line removed.
Steve
-
@stephenw10 said in PHP Fatal error : Cannot access offset of type string on string /usr/local/www/status_interfaces.php:137:
Upgrades for aarch64 (1100 and 2100) are disabled temporarily whist we fix the upgrade bug hitting systems with older installs. https://redmine.pfsense.org/issues/13967
Should be back soon. We have a good handle on what's happening there now.
So if you want to test that now you can install 23.01 clean and import the config with that line removed.
Steve
Hi, sorry for being so quiet, but have struggled with the device all evening.. :/ I had somehow managed to turn off some DNS rules I needed and never thought of checking. I went ahead and did a clean install of 23.01 and imported my saved config. After removing the line you suggested, the interface issue was gone. But instead checking the 'System / Update / branch' it was empty, and I had no packages available to install. So am back on 22.05 again. Getting a little tired jumping back and forth, always something I miss that complicates things a bit. Come to think of it, when logging in to 23.01 for the first time it gave a yellow banner that it was loading packages... But if my DNS was borked, that may well explain why it failed and none were available. But still, should the branch be empty?
Nevertheless, I'm happy to hear you are homing in on the issues with the 1100 & 2100.
-
Hello again,
@stephenw10 Do you need more information to resolve the issue https://redmine.pfsense.org/issues/13981 ? Is it planned to be resolved soon ? Thank you
-
@stephenw10 said in PHP Fatal error : Cannot access offset of type string on string /usr/local/www/status_interfaces.php:137:
install 23.01 clean and import the config with that line removed
Stubborn as I am, I did this once more yesterday, and had great result this time. I haven't found anything malfunctioning this time, other than the restored backup contains the tags that needs to be removed after upgrade/restore (or by modifying the xml file prior restoring)