No. It's in 2.5.0, but won't be copied back to 2.4.5. It's too late and the changes required for that are too large. (And IIRC it may also require PHP 7.3 and OpenSSL 1.1.1 for some parts, but I might be misremembering that).

We're working on migrating the builds over to a new coordinated system that is not only faster but will have consistent timestamps for everything across all builds that start at the same time. It will trigger at set times, multiple times per day, rather than on demand as commits happen, but can still be set off manually if we want.

Other than the timestamps being more "even" in most cases, it should be transparent to users.

The timestamp on the individual images will be when the entire build run starts and not necessarily when that kernel build timestamp happens.

I think we found/fixed most of those unquoted strings some time ago, but there is always a possibility that more are lurking.

The <shaper> section wouldn't show what the wizard had in it that led to the original error, but if you look in <ezshaper> that holds the wizard data.

I'm not trying to be disrespectful friend, just you didn't mention whether it was running or functional afterward, nor an actual complete error line so hard to start troubleshooting. :)

Finding out if it starts properly from the webconfigurator after full up compared to at startup can potentially be a valid troubleshooting step that would lead to the cause.

edit:
Just built fresh 2.4.4_release-p3 vm and installed full squid package. As far as I can tell, every single edit to the squid configs generates a similar line in the logs. Restarting the machine also puts one in the log every single time. Tested the blocking function with the clam functions and with another vm successfully blocked the eicar test file...

While I cannot confirm or deny that the line is or is not an error, I think I can confirm that it existed before the 2.4.5 development freeze and that it has zero impact on functionality and probably not a blocker.

edit#2:
To clarify OP and my ???? in response the actual log line from normal config edits:

php-fpm 766 /pkg_edit.php: [squid] - squid_resync function call pr: bp: rpc:no

and

php-fpm 767 /pkg_edit.php: [squid] - squid_resync function call pr: bp: rpc:no

Actual log line from normal bootup:

php-fpm 339 /rc.start_packages: [squid] - squid_resync function call pr: bp: rpc:no

@yon-0 said in pf2.4.5 setup DHCP Static Mappings then lan down.:

so I tried various parameter settings

What? You don't just randomly change shit that has zero to do with anything hoping it fixes something

dhcp has NOTHING to do with a device talking to another device... Its just a method to hand out info.. Doesn't matter if its reserved so client X gets specific IP or other info, or from a pool where client gets a random IP or static..

Again if you are not actually going to provide info, and just say shit is not working nobody can help you! Lets see this device that has an IP and mask in your network trying to ping the pfsense IP 185.x.191.1 - Can it ping that or not? If not what are the firewall rules on the interface of pfsense...

Etc... This got to be one of the most frustrating threads I have ever.. Again - there must be a language issue and I highly suggest you seek help in your native language.

I opened an issue and pushed a fix for the PHP error: https://redmine.pfsense.org/issues/10255

Then you can't use OpenSSL 1.1.1. It will not work.

Ok, I’ll wait as you suggest.

It is working fine on 2.4.4-p3, both UPnP and Avahi.

It's already been fixed in the repo, new images have been building for a while, should be up any time now.

The devices / drivers are named after whatever first supports them and they are named that upstream. It would be confusing if we changed that. Hence x86-64 architecture is known as amd64.

Steve

diff radvd.conf radvd_ng.conf 59c59 < RDNSS 2620:fe::fe 2620:fe::9 2a00:1098:2c::1 { }; --- > RDNSS 2620:fe::fe 2620:fe::9 2a00:1098:2c::1 2a00:1098:2b::1 { };

It's more of a slush at the moment. We are only committing things there which are regression fixes or fixes for other showstoppers we find when testing. There are still a couple things hanging out there, mostly on our internal Redmine for the hardware we sell. For example there is still an issue we're working on with crypto on the SG-3100.

@skogs It got a shot of pfSense steroid! ☺

@Gertjan yes

The -latest files are a link to whatever the most recent timestamp is. It's a convenience link to get the most recent at that time. I would not use those, as you won't necessarily know from looking at the name if what you downloaded before is the most recent at a later date.

So while it may be true that the ones you asked about were the same when you looked at that moment, that would not necessarily be true by the time someone else looked.