Steve,
Thanks for your help. I did not have any option to choose. During the initial install it performed an update automatically. I don't recall seeing any options for versions.

I just double checked my version here is what I have running:
22.05.1-releease (arm64)
built tues dec 6, 15:43.34 UTC 2022
FreeBSD 12.3-stable

I do now see a update available for 23.01. This was not showing yesterday.

Thanks in advanced Joe

@chrcoluk said in Speedtest CLI. Run speedtest on pfSense box:

For modern pfSense

Not for my 23.01 then, as it doesn't have python3.8

I just followed these instructions:

https://benheater.com/integrating-pfsense-with-wazuh/

and I have the agent installed on pfSense 2.60 CE, with events registering in my Wazuh dashboard. So it works!

The key was getting the NMC to the latest firmware.

@Donkey Kong said in ntopng errors in system log:

I am seeing the same error on my pfsense. Anyone else seeing the same issue? What is the solution to fix it? Thanks!

I have the same problem but haven't found a solution yet.

@dominikhoffmann: My Smart-UPS has a USB-B jack. Connecting a standard USB-A-to-USB-B cable to the white USB jack on my Netgate 1100 allows apcupsd to communicate with the UPS.

I installed directly from freeBSD ports. Conflict with openLDAP.

oh i forgot to tell that the packages are available before but when want to use it, it cant be use.

@krumx Hello,

This doesn't help much at the moment however, they do have an open ticket for this issue. Just not sure when it will be fixed but at least we can track it here and update as soon as possible:

https://redmine.pfsense.org/issues/13985

@iftvio

Hello!

The propriety of multiple CNs in a cert notwithstanding, and not knowing exactly which version you are running or the intent of the original design goals with regards to handling multiple CNs, a quick code review of your suggested fix would indicate that it may not work in all situations.

Among the possible issues:

$is_wildcard will be set based on the last CN checked in the array. str_replace will return an array when the subject ($cert_cn) parameter is an array, which will cause subsequent calls to substr that reference $cert_cn_regex to fail.

A quick hack might be to simply set $cert_cn to the first/last CN in the array, when present.

Of course, any code changes should be fully unit tested.

John

Thanks steve! I'll check them out!

@nogbadthebad

For information, here is the right syntax :

Called-Station-Id =~ '.*:ssid_name'

or in case you want to catch the complete value (ie > "mac:ssid") :

Called-Station-Id == "aa-bb-cc-dd-ee-ff:ssid_name"

-> Now, user is connecting ONLY to one ssid.

Thanks a lot for helping me to fix this setup 👍

@giyahban
Strange thing happened when I changed every 127.0.0.1 ip to lan ip
now its working!
it would be nice to understand what was causing the problem!

@viragomann ill give it a shot... thanks

@dominikhoffmann said in Interact with APC UPC via apcupsd or nut?:

Which package should I use to interface my pfSense box to a UPS? apcupsd or nut? Assume the UPS is one from APC.

If you are looking at single host with an attached UPS, either package is a fine choice. Matter of preference. If you are looking to coordinate shutdown of multiple machines, NUT would be the preference.

Hi Dominik

there is already a redmine ticket and other threads dealing this issue https://forum.netgate.com/topic/178822/no-available-packages

@konjugatix

allright, ive done a factory reset and switched my dyndns provider, this one messed up and gave my domain the wrong ip. Now ive got my domain set up with the correct ip and have started again.

To this day, i have opened ports 80&443 on my appliance, though when i do a nmap on the IP/domain from outside the network(s), only port 80 is open, does anyone have had a similar issue? I made a simple rule WAN->Tis firewall (Self) with tcp on 80 and the same for 443 in a separate rule.

The filed bug gave a good hint about not having an empty HA-Sync configuration under 'System'. I've put a username and password in that configuration to make sure it's not empty.

This results in a working upgrade, and working Freeradius after upgrade. XMLRPC also works fine after the upgrade.

@dennypage avahi just doesn't work - there are multiple steps required to get it working with firewall rules, and all that would be would be discovery. It wouldn't allow access.. its mdns..

@johnpoz
yup, that was it. I haven't installled a router in a while with pfsense and I guess I completely forgot about the need to rehash?

But I installed screen and vim no problem. Some packages need a rehash and some do not?

Thank you all for your comments

Yesterday, I reinstalled my apcupsd and now my widget is working again.

@hugo-santos

Hah, that's not much of a fix but I'm glad you're all set :-)

I find is use AX93304 this lcd.What is this driver use?

@dbmandrake said in Arpwatch reports bogons frequently:

check back in 2.7.0 (which will have a FreeBSD 14.0 base)

I'm on 23.01 so I would think/hope that on the latest binary, its for sure binary for freebsd 14..

If for sure seems like there are few different issues at play.. I had not played with arpwatch in long time, didn't even have it installed. There was an issue awhile back, where would cause a lockup.. And I had removed it back then..

But yeah there sure seems some work needs to be done to make it less log/notification spammy that is for sure..

I know reporting issues or requests for stuff upstream quite often can take some time - There was an issue with dhcp ttl in freebsd long time ago that I had reported.. Took 2 years for them to finally fix it. Reported in 2012, not fixed until 2014 almost exactly 2 years between.. Maybe things reported by netgate can get more traction?

I had fixed that myself and provided the update to anyone that wanted it with new compile of the dhcp client - maybe we could do something ourselves with arpwatch.

@viragomann said in rsync installation:

pfBlockerNG is even mandatory on pfSense.

👍 😁

@inack1986 It seems that you have encountered an issue while trying to install the agent on port 32961, which is the local port for Docker. It appears that the agent crashes when you attempt to use this port, while it runs without any issue on port 10050, but there is no server listening on this port.

There could be several reasons for this problem, including a configuration issue or a conflict with another service running on the same port. One possible solution would be to check the configuration settings for the agent and ensure that it is set up correctly to listen on the desired port. You may also want to verify that there are no other services using the same port, which could cause conflicts and prevent the agent from running properly.

If the problem persists, it may be helpful to reach out to the support team for the agent to see if they can provide further assistance in resolving the issue.

I hope this helps, and please let me know if you have any further questions or concerns.

Noticed this was working again this morning, version is now 9.4.7, so I am guessing this was a bug.