Today I updated pfsense to the version "2.4.5-RC (amd64) built on Thu Feb 27 00:05:35 EST 2020" and the problem with Dynamic DNS is gone.

Thanks!

@jimp i try to to customize the code for my Owen purpose still it don't run after i gate the code

It has a well view, what did you use to improve your traffic graph? I still have some problems with and even more when I try to upgrade my Ip man is such horrible haha. I like you css style, well done bro!

I didn't get an error message, but bumping from 0221.1500 to 0225.2100 took me a solid 30 minutes. Not quite sure what the hold up was.

They are on a timer now and not triggered by any specific change as before. Keep an eye on Github and Redmine and see if anything interesting changed between what you have and the current one.

If it makes it into OpenSSH sshd in the base system FreeBSD, perhaps. But doubtful.

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