@geoffb I can confirm that the parsing of the NTP block is buggy and we can reproduce it on all the uses cases. For the moment, the NTP field is not functional.

@yon-0 said in some services show can't start:

Updating pfSense repository catalogue...
pkg-static: No SRV record found for the repo 'pfSense'
pkg-static: An error occured while fetching package

This is a DNS error. Check pfSense can resolve.

Do you have an upgrade log from that?

Is it running an packages? We have seen some upgrades fail due to ram exhaustion that present as you see after rebooting.

Steve

Steve,

OK, thank you for the clear answer regarding all "netgate" equipment

@DrPhil

So I tried booting from the USB again. I had by now lost the fear of just unplugging the device and restarting with the bootable usb plugged in.

It showed me output this time. I think I was missing hitting space. I was hitting enter but that was not enough.

Anyway, as it started to install it wasn't able to find my config from the existing file system. Luckily I found the instructions that said you can put config.xml onto the USB itself (same folder that has the readme). It seems to have worked.

The household has internet again, i.e. less yelling at me.

@RobbieTT said in 23.09d - Is QAT Broken?:

Wendell has just posted this video on QAT and where it should be used:

qat:Speeding SSL with NGINX

Clearly I agree.

☕️

Right on...wished he had also test on FreeBSD...

@NollipfSense Yah, it's fixed in the 23.09 release build, just updated to it and no issues with Suricata staying :)

Hmm, Ok. I'll see what else I can find. As far as I know though we haven't seen any other reports of that.

Today I removed vlan 35 from pfSense, and tagged it on the switch with a port pvid 35 back to pfSense. That got rid of the below errors, but wg gateways were still disabled. I find that interesting, but it did not fix the problem.

Restarting dpinger with cron at boot does fix it, as posted in a thread here somewhere.
@reboot root sleep 30 && /usr/local/sbin/pfSsh.php playback svc restart dpinger

So, I am back to these 3 lines (in bold) do not show-up on the vm, but they do on the bare metal:
Oct 30 10:45:55 php-cgi 478 rc.bootup: The command '/sbin/ifconfig 'pppoe0' inet6 -ifdisabled' returned exit code '1', the output was 'ifconfig: interface pppoe0 does not exist'
Oct 30 10:45:55 php-cgi 478 rc.bootup: The command '/sbin/ifconfig 'pppoe0' inet6 fe80::baca:3aff:fe8d:70b2%em0.35 delete' returned exit code '1', the output was 'ifconfig: interface pppoe0 does not exist'
Oct 30 10:45:55 php-cgi 478 rc.bootup: The command '/sbin/ifconfig 'pppoe0' inet6 ifdisabled' returned exit code '1', the output was 'ifconfig: interface pppoe0 does not exist

@Patch yes

Either should do it.

@jimp said in RC - Page access:

page times out (login session expired).

could be, but I was no where near what I normally have the session timeout set for.
and since then I have hit the "session timeout" many times, by setting an arbitrarily lower value to make it time out sooner. Every time I get a nice little dialog telling me the session has timed out, and clicking on ok /next or whatever the button says, takes me directly to the login page as expected.

I'm not too worried about it, seems to have been a one off, unexplained event at this point. Not a show stopper.

Thanks

@stephenw10

After a while (could have been a sooner than the hour or so, I checked again after lunch) it must have reached out and or processed itself into the correct version list..

it now shows "Next Stable Version 23.09 RC" and "Current Stable Version (23.05.1)"

It just took a while.
No issue it is just in the smoke and mirrors.

@stephenw10 said in 23.09.rc Displaying 'later version than official' flag:

unless you force it

I took that to mean go for lunch

Thanks

@marcosm
@marcosm said in Default IPv4 Route missing and DNS Resolver issue every reboot - 23.09.a.20231003.0600:

Does this happen in 23.05.1 as well? It sounds like there's something removing the route after the reboot - the system logs may have something interesting about that. Does the gateway address fall within the WAN subnet (i.e. is it a non-local gateway)? With the gateway offline and the monitor IP back as 1.1.1.1, try executing the PHP command system_routing_configure(); under Diagnostics > Command Prompt - does the default route come back?

Apologies for the delay in reply. Yes, I upgraded to 23.09.a.20231003.0600 because I was having this same issue on 23.05.1. The gateway does fall within the WAN subnet. The WAN interface has an IP address with a subnet mask of 255.255.254.0. The gateway IP address has 224 in the third octet (x.x.224.x) and my WAN interface IP address has 225 in the third octet (x.x.225.x). It looks like they are within the same WAN subnet.

I changed the monitor IP back to 1.1.1.1 and rebooted the router. I checked Diagnostics > Routes to see if there was an IP route for 1.1.1.1. There was and it's gateway was set to the IP address containing 224 (x.x.224.x). The internet is still not working. Then, I ran the system_routing_configure() command in the PHP command box.

Immediately after running that command, a default route appeared in Diagnostics > Routes and its IP address is the gateway with IP address containing 224 (x.x.224.x). My Internet is now working again.

How can I configure the router to have it do this automatically? Will it require a system update?

@stephenw10

Done as Issue #14915

Louis

Thanks Jim, yeah my config is as you say. DHCP6 on WAN, LAN tracking that, but with DHCPv6 off on the LAN and only using SLAAC.

Good to see you were able to replicate it and found a fix as well!

Hmm, that is indeed curious.... 🤔

@jimp I appreciate that ISC DHCP Server has reached EOL and as a result they do not expect to release any additional updates. I also understand from their announcement that ISC recommends that new users consider Kea DHCP over ISC DHCP.
My concern is that in the context of pfSense the integration of Kea DHCP is not yet complete. pfSense end users do not view ISC DHCP as a separate product or feature. My suggestion is that pfSense hold off on advertising ISC DHCP as deprecated until after the pfSense development team believes that the integration is feature complete and all of the transitional issues have been exposed. Once the pfSense integration is declared stable; then begin issuing "deprecation warnings" to push administrators to switch over.

To assist in finding outstanding issues I suggest that any state which is generated by ISC DHCP or Kea DHCP be wiped when administrators switch between the two implementations. For example, any DNS entries created for static or temporary DHCP leases should be removed. Otherwise, if Kea DHCP doesn't support the generation of DNS entries the administrator won't discover there is a problem until the DHCP configuration changes. At that point chasing down why a DNS entry wasn't created or why a DNS entry for the wrong address exists will be quite painful.

Thanks for listening even if you disagree with my point of view.