• I'm running the 2.4.4 (p3) release on both of my firewalls and did a upgrade of the frr package to 0.6.4_3 (frr 7-7.2_1) and now frr won't start on either firewall and there's no errors or reason why. I would like to know if there's a way to downgrade to an earlier version of the frr package? Otherwise, I guess BGP is broke until I can upgrade to 2.4.5 and hope that fixes the non-start. I've had a couple of other packages do the same, net-snmpd and lldp specifically, but the frr is the one I am needing the most.


  • @jlw52761 I take it that Status > System logs > Packages had no log entry...if that's the case, I would reinstall the package...unless you had tried that also.


  • Nothing under system logs, either in the GUI or in the console. I have also uninstalled and re-installed, with no luck.


  • @jlw52761 said in Downgrade packages:

    Nothing under system logs, either in the GUI or in the console. I have also uninstalled and re-installed, with no luck.

    Go have a look at this thread: https://forum.netgate.com/topic/151709/2-4-5-update-caution/. You will need to update to pfSense-2.4.5 BEFORE updating any packages. The 2.4.x RELEASE repository now contains FreeBSD 11.3 packages, and many of them are not compatible- for various reasons- with the old FreeBSD 11.2 that pfSense-2.4.4 was based on.

    I don't know for sure, but my educated guess is the frr package is failing to start due to a missing or incompatible dependent library. If you know what binary the package launches, you can try launching that binary from the command-line yourself to see what errors are thrown.

    Unless you have some known hardware issue, you should go ahead and update to pfSense-2.4.5 anyway.

  • Banned

    This post is deleted!

  • @bmeeks I did start the binary manually and no output whatsoever. I also went into the repo config and set the branch back to 2.4.4 and went to do an update, which at first did start pulling down the old package and such, but then wanted to uninstall pfSense itself, so that was buster.

    I'm concerned on the lack of safety checks around the updates and the automatic assumption that everyone will automatically move to the latest and greatest the moment it comes out. This, from an enterprise and business continuity standpoint, is a bad stance and needs to be addressed. The package manager repo config should not have been switched to the 2.4.5 branch until I upgraded to it, instead of trying to force me into that route. There also needs to be better consistency checking on the package version against the OS version. Every other package manager I've ever used, APT, YUM, etc all do this, so not sure if this is a FreeBSD gap or a pfSense gap.

    I do want to end by saying that I switched to using pfSense for a reason, which is the stability that has been touted by the community and the rock solid networking stack that FreeBSD is known for, but there's many little things like this issue that prevent me from recommending this more broadly. I hope folks pay attention and are willing to grow from these posts, not just say "it was posted to not upgrade packages even though you are allowed to". That's not good UX at all and will put many folks off.


  • @jlw52761 said in Downgrade packages:

    @bmeeks I did start the binary manually and no output whatsoever. I also went into the repo config and set the branch back to 2.4.4 and went to do an update, which at first did start pulling down the old package and such, but then wanted to uninstall pfSense itself, so that was buster.

    I'm concerned on the lack of safety checks around the updates and the automatic assumption that everyone will automatically move to the latest and greatest the moment it comes out. This, from an enterprise and business continuity standpoint, is a bad stance and needs to be addressed. The package manager repo config should not have been switched to the 2.4.5 branch until I upgraded to it, instead of trying to force me into that route. There also needs to be better consistency checking on the package version against the OS version. Every other package manager I've ever used, APT, YUM, etc all do this, so not sure if this is a FreeBSD gap or a pfSense gap.

    I do want to end by saying that I switched to using pfSense for a reason, which is the stability that has been touted by the community and the rock solid networking stack that FreeBSD is known for, but there's many little things like this issue that prevent me from recommending this more broadly. I hope folks pay attention and are willing to grow from these posts, not just say "it was posted to not upgrade packages even though you are allowed to". That's not good UX at all and will put many folks off.

    @jlw52761:
    I am a volunteer package maintainer for Snort and Suricata only. I have no involvement with anything else. I chimed in on this thread just to offer a suggestion.

    I will say this in defense of the pfSense team. This is free software. They make their money by offering support and through the selling of hardware. If you were paying tens of thousands of dollars per year for a software license and support, then your beefs about UX would carry weight. When you beef about free software, the complaints don't carry much weight ... ☺.

    Not trying to hammer you here, but just pointing out that free open-source software has its advantages and disadvantages. And you have to be willing to accept them both when you use free open-source software.

    As an open-source platform, pfSense freely accepts user-submitted code updates through pull requests submitted via their Github repo. If you have better methods for handling upgrades, they will gladly review any code you submit for inclusion in the package. That is a big advantage for free software. Try submitting a pull request with improved code to Apple or Microsoft and see how far you get ... ☺ .


  • @jlw52761:
    And to continue my last thoughts (again, don't take offense here, I'm not attacking you). This post is just to better explain why some decisions are made in the software world.

    The interraction of shared libraries in all operating systems has gotten to be more and more of an issue. I have been programming for many, many years. All the way back to Z80 and 8080 microprocessors at the machine-code level in the late 1970s. I remember when Windows first gained in popularity how all the Unix guys made fun of the "DLL Hell" that Windows created with shared DLLs (dyanmically-linked libraries). You could have multiple versions of the same DLL installed on a PC and consequently experience weird crashes in various applications depending on which version of a DLL was in the search path and got loaded. Fun times -- NOT!

    Well, fast forward to today and you find that all the popular Nix-based operating systems have their own version of "DLL Hell" caused by shared libraries. That's what's going on with Snort and possibly what's going on with frr (not 100% about frr, though). With Snort it's due to an upgrade to the dependent library libpcap. The newer shared library (used by Snort to actually capture traffic on an interface) in turn has its own shared library dependencies that FreeBSD 11.2 does not satisfy. Trying to cope with all this and keep the overall system architecture manageable is a challenge. Especially so when the software you are building is offered free to the users.

    You want to keep the overall system somewhat flexible so it can rapidly respond to security issues. So an easy way to do that is to basically force your user base to stay "current". Without the baggage of having to ensure legacy support for old stuff, your programming life is a little easier and you have more resources to devote to both new features and responding to security issues.


  • Not sure how the discussion went into DLL hell, which as a developer myself I understand completely, but not sure how that applies here.

    Looking through the forums, there are a lot of folks having many issues with 2.4.5 and would like to be able to go back to 2.4.4, which even if they install 2.4.4 the packages force themselves to the 2.4.5 branch of the GitHub repository.

    The point I'm making is that we should be able to stay on the 2.4.4 release for as long as we want, and not be forced to the 2.4.5 branch like we are. I would gladly accept that on the 2.4.4 branch I would probably not get new package updates, but I would be assured that the packages being offered will work on my install.

    Also, having the package have the metadata to state that the dependent package needs to be above x and below x is not unreasonable and happens all the time. Maybe this is something that is actually a gap with pkg itself and not a problem with the packages, I am not familiar enough with FreeBSD's package manager.

    As for the argument of free software and you get what you get, that's not the best stance by a company that puts out free software and makes money from support of said software. As a home user I don't need the paid support, but software that I use at home, like pfSense, that would translate to work is something that I look into all the time. In this case, I would, before today, love to run pfSense at work and pay for the support, but with these issues I can't honestly trust the system in my critical work environment with these short comings using the same codebase that I am using at home.

    Also, I did purchase a SG-1100 for my second home, which comes with the commercially supported version of pfSense, so the argument of "you get what you pay for" doesn't apply because I did pay for the support and for the expectation of rock solid UX experience and software and I did pay for the hardware, and I'm not getting that experience. There's a number of folks in the forum that have issues with 2.4.5 and would like to go back to 2.4.4_3 and have purchased hardware from Netgate, so I think that the point is moot.

    Now back to the original issue, I did upgrade to the 2.4.5 branch and have been fixing all kinds of little things, like pfBlockerNG not being able to update correctly, etc, but the frr is now working again.

    I absolutely would not recommend this for any critical infrastructure at this point, or make sure that updates don't happen until the update has been in the wild for a long time, a few months at the minimum, which is not good from a security perspective and isn't even possible from what I see to stay at a -1 version for production.


  • @jlw52761:
    I hear what you are saying, but expand your argument to the other "big two" software companies out there -- Microsoft and Apple. Once either of them release a new OS version and announce an EOL for a legacy version, they both will eventully remove the legacy version. For example you won't find a Microsoft link to download Windows 7 now. So pfSense is not totally unlike them. pfSense released a new version with a number of security fixes and immediately made the old version with its unpatched vulnerabilities EOL. Yeah, they had an option of not removing the methods for installing or reverting to the old version, but I can see how they would think that confers some responsibility and risk onto them for continuing to provide access to software with known security vulnerabilities. The better approach would be to coax users into upgrading.

    Everytime there is a pfSense upgrade, and most especially when it involves a decent bump in the underlying OS version (this time from FreeBSD 11.2-RELEASE to 11.3-STABLE), there are cries from some in the user base to revert to the old version until some specific bug is fixed. Truth is, most of the user base is seeing no impact of the upgrade. It's like every other software forum. It's only the folks who are having issues that post. But count the entire total number of those folks here posting about 2.4.5 problems and you still may not come up to 100 individual users (don't count total posts, count specific users posting with issues directly related to 2.4.5). You might be less than 50 even. Now divide that number posting about 2.4.5 issues by the total number of pfSense-2.4.5 downloads and a new perspective on the upgrade will emerge. It will show as pretty darn successful. Or else a ton of folks worldwide have broken systems and have not said a word about it ... ☺.

    My rabbit trail into "DLL Hell" was an attempt to illustrate the complexity of modern software with all of its inter-dependencies. In the case of Snort, the binary has in its Makefile some build and runtime dependencies. But those dependencies in turn have their own build and runtime dependencies in their Makefile, and the maze gets deeper and deeper as those dependencies in turn have their own and so on.


  • Unfortunately your comparison doesn't hold much weight because every software vendor I've ever dealt with, Microsoft, Apple, VMware, Cisco, Palo Alto, Ubuntu, etc all maintain support for multiple versions and don't force folks to the "bleeding edge" regardless of issues. In fact, look at what has happened to Microsoft and Apple over the last 2 years, they are having to move to the stance of allowing users to defer updates instead of forcing issues, like loss of data.

    By saying the majority of folks don't have issues and only those that have problems post is discouraging those folks from posting or pointing out problems due to fear of being singled out.

    Now I don't know about some folks, but 20+ years in the enterprise infrastructure has taught me one constant, bleeding edge in production is the quickest route to disaster, and the method that Netgate is taking flies in the face of stable production.

    Now, with that, I have upgraded both of my firewalls to the 2.4.5 release, and guess what, frr still will not start on one and not run reliably on the other, and there's no log entries or indications of why the situation is occurring. If I had this running in my business and I lost BGP in this fashion, I would no longer have this vendor in my environment. Plain and simple.

    I understand Netgate tries to test and validate as much as possible before releasing new software, but the reality is they cannot test for every possible use case and scenario, and I wouldn't expect them to be able to either, which is why I would rather have the option of testing a new release in my lab before being forced to place it in production, or have the option to hold off any new releases for several weeks. Personally, I do not want my production to be anyone's guinea pig environment, and I avoid testing in production at all costs, and the current way Netgate does the software push doesn't allow me to easily do this.


  • @jlw52761 said in Downgrade packages:

    Unfortunately your comparison doesn't hold much weight because every software vendor I've ever dealt with, Microsoft, Apple, VMware, Cisco, Palo Alto, Ubuntu, etc all maintain support for multiple versions and don't force folks to the "bleeding edge" regardless of issues. In fact, look at what has happened to Microsoft and Apple over the last 2 years, they are having to move to the stance of allowing users to defer updates instead of forcing issues, like loss of data.

    By saying the majority of folks don't have issues and only those that have problems post is discouraging those folks from posting or pointing out problems due to fear of being singled out.

    Now I don't know about some folks, but 20+ years in the enterprise infrastructure has taught me one constant, bleeding edge in production is the quickest route to disaster, and the method that Netgate is taking flies in the face of stable production.

    Now, with that, I have upgraded both of my firewalls to the 2.4.5 release, and guess what, frr still will not start on one and not run reliably on the other, and there's no log entries or indications of why the situation is occurring. If I had this running in my business and I lost BGP in this fashion, I would no longer have this vendor in my environment. Plain and simple.

    I understand Netgate tries to test and validate as much as possible before releasing new software, but the reality is they cannot test for every possible use case and scenario, and I wouldn't expect them to be able to either, which is why I would rather have the option of testing a new release in my lab before being forced to place it in production, or have the option to hold off any new releases for several weeks. Personally, I do not want my production to be anyone's guinea pig environment, and I avoid testing in production at all costs, and the current way Netgate does the software push doesn't allow me to easily do this.

    What I said about who posts and who does not is generally true. It's not meant to single anyone out. Just to point out that it is not a reliable indicator of how "bad" some particular issue may be.

    No matter. My intent was not to pick a fight with you or argue. Just wanted to point out there are reasons for how some things are handled when it comes to free open-source software.

    However, in this instance Netgate/pfSense has taken a rather out-of-the-ordinary step of making the prior 2.4.4_p3 release available again, including packages compiled for 2.4.4._p3. Search the recent forum posts and you will see how to roll back.