@stephenw10 Ah that’s interesting. So custom config within packages are Base64 encoded. Nice! @stephenw10 Thanks for the help. decoded the before and after and changes are recognized.

Yes, do not attempt to install packages if the update repo branch is not set to the same version you are running. It probably isn't in your case which is why it's failing to pull in the package list. But you should upgrade to the current version before installing pkgs anyway. You may have to resave the selected update branch or select a different branch and then move back to 'current stable version' to see it.

@yeahmagnets after mac authentication, it worked thank you guys

OK, theoretically you should be able to upgrade to 2.7.2 eventually by upgrading through the various versiopns. However I would not do that. Take this opportunity to reinstall 2.7.2 clean. You can install as ZFS at that point too. Then restore your config into it.

@GiaNN i'll do some other testing because it seems that so It won't send any message besides the test one

Hello and thank you for this information, I also confirm that it is now corrected!

@diyhouse said in Crash Report: And further,.. have just updated as follows:- Installed packages to be UPGRADED: pfSense-pkg-suricata: 7.0.2_1 -> 7.0.2_2 [pfSense] suricata: 7.0.2_4 -> 7.0.2_5 [pfSense] I guess there are some other little fixes being applied. But one last question,... looking at the end of the update log stream... I get the following,.. Executing custom_php_resync_config_command()...done. Menu items... done. Services... done. Writing configuration... done. You may need to manually remove /usr/local/etc/suricata/classification.config if it is no longer needed. You may need to manually remove /usr/local/etc/suricata/reference.config if it is no longer needed. >>> Cleaning up cache... done. Success . if it is no longer needed.,.. how do mere mortals know if it is needed or not,... do I need these files, or not? Tx @stephenw10 has the correct answer. Instructions you see scroll by at the end of the binary portion of package installations are meant for consumption by folks using the package on plain-vanilla FreeBSD installs with no GUI. Those messages should be ignored by pfSense users. Since they are bundled with the binary as it comes from upstream, removing them or customizing them for pfSense would mean making and maintaining edits for every single third-party package. Not worth the effort. That file was formerly used by Suricata, but is no longer required and is ignored. It hurts nothing to still have it in the distro, though. Snort does still want that file, so that's why it remains for now.

Yup there's no animosity toward @JMV43-0 here. After reading that article asking questions about it is completely legitimate IMO. For clarity see our SA for this here: https://docs.netgate.com/downloads/pfSense-SA-23_10.webgui.asc The impact of this is completely overblown. For a remote actor to exploit this the webgui must be open to the internet and they have to be logged in as a user that can access those pages and make changes. If they can do that you probably have bigger issues!

Hmm, interesting. I don't recall there being an issue in 23.05. Still glad you were able to get past it.

@stephenw10 said in [Crash Report] - Crash after update from 2.6.0 to 2.7.0: Which is fixed in 2.7.2. Cool - thank you. As I just wrote in my edit I managed to upgrade it to 2.7.2, so it probably won't happen again.

@johnpoz said in After Update 2.7.2 / 23.09.1: auditors are idiots - most of them are, and many of them don't even understand what is going on No argument here on any of the statements you've made in that but especially the line quoted above ... I too have been around this block way to many times. I'm not expecting the pfSense folks to fix anything in this regard, just more of "would be really nice if" type comment. Versioning is a big issue and as we all know fixing at the level we are talking about is unlikely happen. Why do I need to change the emergency admin passwords, that are unique for every machine and locked in the safe in a sealed envelope every 90 days Right? The answer of course is "because of the auditors" You might have jump off a cliff and take the other people that have access to the cabinet with you. Then it is someone else's problem how to get into the locked cabinet and more technically challenging, open the envelop. Fair Warning: I'm taking the combination or key or whatever it is with me... just sayin' (wait is the combination/key is yet another locked and secure location?) ... I was actually in a location not too long ago where all the locked in a cabinet requirements where followed. But then there was a yellow sticky note on each machine with the alternate admin account password stuck to the side of the machine. Brilliant, why didn't I think of that. That was fun. Shake your head, walk (no run) away. There should be a forum group/branch for "Audit Insanity" that would be fun!

Yup, we probably need to change the wording there to make it clearer in the next version. From 2.7.1/23.09 the user needs to opt-in by selecting to new 'current stable' branch to upgrade. Steve

@stephenw10 ah ok and then no one really has answers cuz they dont see it.. i get it and the 1 offs its hard to deal with ya its confusing like it works and doesnt work go figure right nothing is perfect.... (: but i appreciate the help so far least to try to do it.. or i just stick with the VPN clients and let the wan comps connect to just the prefill cache i dunno how will it works all together i havent tested it much as its only used for prefill when i use the lancache i actually use the pfsense 192.168.0.1 and it points to to the lancache lol always learning (:

@stephenw10 i'm familiar with it all enough now so that i can get around it... as long as they don't start changing things just for the sake of changing things such that things that once worked properly/perfectly are now broken.. feels like thats going on with 2.7.1 & 2.7.2

@johnpoz I didn't actually say anything about the results. Just showing you what I'm seeing on a system with little to no other traffic and no masked IP's. the buffer bloat test as you know downloads first, then uploads. so those first captures are yes at the point that is nearing the end of uploading test here is a capture while it is still in the download phase (local filter) [image: 1702317041720-screen-shot-2023-12-11-at-12.49.40-pm-resized.png]

Well use the client as destination then. What ports is it using? If they are fixed you can include that to be more specific. But check it really is re-opening states from WAN first.

@Goosewire Wrong category… As suggested on Reddit try contacting Protectli for the boot issue. There might be something in the logs. A power outage wouldn’t log anything and would explain why the switch booted. Consider a UPS…?

@stephenw10 Thanks Stephen for confirming. Now that it is enable, I will never turn it off .

@rpotter28 yup - same here more info here https://forum.netgate.com/topic/184681/after-update-2-7-2/8?_=1702253232490 now the only package I can see that got upgraded during the 23.09.1 install was pfBlocker from _6 to _7 certainly wasn't as a result of me upgrading the package -- it was logged and is upgraded however. The repo servers became unavailable this morning a few minutes after my 23.09.1 upgrade completed.