@Gertjan

Thanks for all of your help with this issue. I'm unsure why yours is working when you use the actual ip address of your server in CRON, but mine is not.

Because of what I saw in the packet capture, I decided to imitate what the GUI is doing. I changed the command in CRON to:

/usr/local/bin/wol -i 192.168.2.255 bc:ee:7b:db:fc:f4

The above command works in CRON to wake up my server. From what you said, I'm guessing this is because "192.168.2.255" is the "broadcast address" of the LAN interface of the $(bcip) as described in your post.

/usr/local/bin/wol -i 192.168.2.4 bc:ee:7b:db:fc:f4

The original command above did nothing and didn't even show up in "packet capture" until after the server was already up and running, then I would get something similar to what you got in your packet capture in your screenshot above, as you can see from my previous post. However, the command with the actual ip address reserved for my server in Pfsense fails to wake-on-lan my server, but 192.168.2.255 does work.

Thanks for all of your advice and help which resulted in changing "4" to "255" and now it works.

It's relevant for me too, thank you for explanation

That error was probably from when the package was being removed. That particular error has been fixed in the 2.7.0 package for quite a long time:

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

Just wanted to post as I ran into this issue today. I was able to fix this by submitting a TAC ticket with my NDI and SN. The team found a mismatch in their database to which they fixed, and I was able to update all my packages.

@NogBadTheBad

I just did that and it stopped, and i think I know why. Those cams use L2 for discovery.

Thank you very much!

@darkcorner

You said in the other thread :

@darkcorner said in Network access blocked after update:

that I now have to configure from scratch..

That's a 'noop' ;)

When you remove all ('big') packages before upgrading, the upgrade process goes much faster.
When you have a copy of that config.xml file, right after the upgrade and reboot, you should import config.
All packages that are marked as "installed and configured" in the config file will get downloaded, installed and configured.
A final reboot and you're ok.
Nothing to reconfigure - with the exception : if there are new options, you should check these packages and make your config choices.

@abuttino said in radtest not found / Problems with FreeRadius:

grr, was using the wrong pfSense server.

not sure why that should matter running the pkg command, I could see it not having freerad installed as to why radtest not there. But the pkg command? Maybe that just generic sort of error since that pfsense didn't actually have the radtest file because freerad was not installed.

@elvisimprsntr said in LCDProc (/dev/cua1) failed (No such file or directory):

@sebr

Looks like the Peplink Balance series LCD displays have the ST7066U (or compatible) LCD controller.

http://lcdproc.omnipotent.net/hardware.php3

Screenshot 2023-05-27 at 10.55.49 AM.png

Is there a /dev/lpt0 port listed?

If so, you might try the following:

Com port: (/dev/lpt0) Driver: HD44780 and compatible Connection type: Likely 4bit or 8bit, but try each until you find one that works.

If not, then it might be connected to a serializer chip, thus /dev/cua*

Thanks for your help, I'll go back and test this.

@Gertjan said in FreeRadius with Windows Active Directory:

You are using "PAP authentication" ?

Should FreeRadius work with Active Direcroty throught NPS Radius or as LDAP autorization? i think it work as LDAP, as there are Base DN Filter and Base Filter attributes. i have configured in pfsense LDAP authentification to web page and there are also Base DN attributes thats why i think it works not throught NPS.
Here is my LDAP web authentification

Spoiler

e1799302-4e6d-427f-8032-f2001e496b0f-image.png

Find the rule that is false-positive triggering on your Gmail downloads and disable it. To do that you will need to cross-reference IP addresses in your alerts shown on the ALERTS tab.

None of the alerts you are showing in your screenshot appear relevant to Gmail.

Sorry, i have the same issue. Any fresh ideas?

Any further questions about the change in 2.2.6 should go over in the new thread:

https://forum.netgate.com/topic/182725/system-patches-package-version-2-2-6

I know this is an old thread, but it is the only one that matches the issues I have had over past 2 days.

I have latest version fully updated pfsense and packages.

I was running HAProxy Devel. Again fully up to date (as of 06/09/2023), given dates as I am unsure what versions.

All of a sudden our RDS users were not able to open applications. In our setup we have a RDS Gateway, people log into the HTML5 interface for RDS, then they open an app in browser. Accessing and loggining into the HTML5 interface worked fine and always worked, even with fully updated.

But when you tried to open an app, it would fail to open. After messing about for a bit, I accidently forwarded 443 to the RDS gateway, and everything was working. Once I learnt this, I had to put 443 back to HAProxy as our intranet was no longer working. WIth this information, I knew it was something to do with HAProxy not handling the connection correctly.

So I uninstalled HAProxy Devel, and installed HAProxy package 0.63_1.

Now everything is working perfectly as it has been for years.

I know its been some time since this thread was made, but what ever that problem ended up being, its happening again. Something is wrong with HAProxy Devel.

@pV5 those are the extra packages that pfsense + gets.. Yeah they would be there by default

i had this issue, solved it after changing "httpforclose" to "httpclose" as the new version doesn't support that old config var, perhaps dev can do some some parsing magic? lucky the error code lead me to this