pfSense Support Subscription

Author Topic: Snap 27 Oct 10:31:57 CDT - broken IPSEC status  (Read 6743 times)

0 Members and 1 Guest are viewing this topic.

Offline Jon Gerdes

  • Full Member
  • ***
  • Posts: 155
  • Karma: +9/-0
    • View Profile
    • Blueloop Ltd
Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« on: October 27, 2015, 12:39:43 pm »
I was hoping to give some feedback on this https://redmine.pfsense.org/issues/5149 (memory leak(s) in strongswan) and so applied this:

2.2.5-DEVELOPMENT (amd64)
built on Tue Oct 27 10:31:57 CDT 2015

Unfortunately Status -> IPSEC only shows some (not all) details on phase 1 and no P2 details.  The SAD and SPD tabs seem OK and tunnels are running.  The dashboard widget is completely broken:

Code: [Select]
Warning: Cannot use a scalar value as an array in /usr/local/www/widgets/widgets/ipsec.widget.php on line 60
Warning: Cannot use a scalar value as an array in /usr/local/www/widgets/widgets/ipsec.widget.php on line 61
Warning: Cannot use a scalar value as an array in /usr/local/www/widgets/widgets/ipsec.widget.php on line 62
<lots more>

The tunnels that really are down, do seem to display correctly though.

Offline cmb

  • Hero Member
  • *****
  • Posts: 11231
  • Karma: +878/-7
    • View Profile
    • Chris Buechler
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #1 on: October 27, 2015, 01:49:17 pm »
The status XML is invalid after the change to vstr. We're trying with builtin instead for other reasons, will re-test afterwards.

That only impacts the status output display, functionally it should be fine if you want to keep running it. 'ipsec statusall' will show the proper status if you want to check it manually in the mean time.

Offline Jon Gerdes

  • Full Member
  • ***
  • Posts: 155
  • Karma: +9/-0
    • View Profile
    • Blueloop Ltd
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #2 on: October 28, 2015, 04:52:30 am »
The status XML is invalid after the change to vstr. We're trying with builtin instead for other reasons, will re-test afterwards.

That only impacts the status output display, functionally it should be fine if you want to keep running it. 'ipsec statusall' will show the proper status if you want to check it manually in the mean time.

I thought it was something like that.  I'm keen to see if the vstr change fixes the ~six days uptime (51 IPSEC P1s) I get at the moment so am sticking with it.  Icinga does the real monitoring around here so a screwy report in pfSense is no real problem.  Just checked your list of open issues - there's only one left!  Attached is a current memory RRD graph, which is already looking a lot happier.

Great work on what is a really tricky bug.  I have gone through the upstream one that was logged and the comment stream reflects very well on the pfSense team's diplomacy skills.  Recalcitrant upstream devs might like to reflect on the fact that pfSense is used rather a lot and in some very large deployments - your userbase stresses the networking components that many others might merely tickle ...

Thanks.

Offline jwt

  • Administrator
  • Sr. Member
  • *****
  • Posts: 322
  • Karma: +87/-14
    • View Profile
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #3 on: October 28, 2015, 05:09:22 am »
it would have fixed it, but the hacks that <someone> put in the smp plugin don't work well with the implementation via vstr.

Offline Jon Gerdes

  • Full Member
  • ***
  • Posts: 155
  • Karma: +9/-0
    • View Profile
    • Blueloop Ltd
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #4 on: October 28, 2015, 05:29:21 am »
it would have fixed it, but the hacks that <someone> put in the smp plugin don't work well with the implementation via vstr.

I wouldn't dream of running through the commits to find out who <someone> might be.  I'll take stable functionality over pretty reports any day.  The classic engineering approach seems to be at work here:  bodge in a solution first, paper over the cracks later 8)  Sorry, I mean find the root cause and develop a solution via a series of progressively better iterations.

Offline djamp42

  • Jr. Member
  • **
  • Posts: 96
  • Karma: +3/-0
    • View Profile
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #5 on: October 28, 2015, 01:38:31 pm »
The status XML is invalid after the change to vstr. We're trying with builtin instead for other reasons, will re-test afterwards.

That only impacts the status output display, functionally it should be fine if you want to keep running it. 'ipsec statusall' will show the proper status if you want to check it manually in the mean time.

If someone can let me know when your pretty much done with the ipsec stuff i can test this on my box.

Offline cmb

  • Hero Member
  • *****
  • Posts: 11231
  • Karma: +878/-7
    • View Profile
    • Chris Buechler
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #6 on: October 28, 2015, 05:11:03 pm »
If you have a situation where the memory leak is a major problem, latest 2.2.5 is significantly better there and only breaks the GUI status pieces. Otherwise, yeah we'll follow up here when the status problem's fixed too, it's being worked on.

Offline jwt

  • Administrator
  • Sr. Member
  • *****
  • Posts: 322
  • Karma: +87/-14
    • View Profile
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #7 on: October 30, 2015, 05:22:59 pm »
it would have fixed it, but the hacks that <someone> put in the smp plugin don't work well with the implementation via vstr.

I wouldn't dream of running through the commits to find out who <someone> might be.  I'll take stable functionality over pretty reports any day.  The classic engineering approach seems to be at work here:  bodge in a solution first, paper over the cracks later 8)  Sorry, I mean find the root cause and develop a solution via a series of progressively better iterations.

given that we completely eliminated the former bodge, you're left to choose from only one of those two eventualities.

Offline Jon Gerdes

  • Full Member
  • ***
  • Posts: 155
  • Karma: +9/-0
    • View Profile
    • Blueloop Ltd
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #8 on: October 30, 2015, 06:16:15 pm »
it would have fixed it, but the hacks that <someone> put in the smp plugin don't work well with the implementation via vstr.

I wouldn't dream of running through the commits to find out who <someone> might be.  I'll take stable functionality over pretty reports any day.  The classic engineering approach seems to be at work here:  bodge in a solution first, paper over the cracks later 8)  Sorry, I mean find the root cause and develop a solution via a series of progressively better iterations.

given that we completely eliminated the former bodge, you're left to choose from only one of those two eventualities.

... and for that I am extremely gratefull:  Our office pfSense box's memory RRD graph has flatlined nicely rather than suffering from severe arrhythmia and regular crashes.

Offline ermal

  • Hero Member
  • *****
  • Posts: 3832
  • Karma: +81/-5
    • View Profile
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #9 on: November 02, 2015, 03:32:42 pm »
it would have fixed it, but the hacks that <someone> put in the smp plugin don't work well with the implementation via vstr.

I wouldn't dream of running through the commits to find out who <someone> might be.  I'll take stable functionality over pretty reports any day.  The classic engineering approach seems to be at work here:  bodge in a solution first, paper over the cracks later 8)  Sorry, I mean find the root cause and develop a solution via a series of progressively better iterations.

given that we completely eliminated the former bodge, you're left to choose from only one of those two eventualities.


Hahhhahahaa it was brought to my attention this thread!

1. You can not find someone since the logs have been erased.
2. Blaming someone/anyone because of ignorance is the next level of ignorance
3. Making someone/anyone guilty because a bug cannot fixed is total incompetence and shows immaturity
4. I feel bad that cmb allows to be talked for someone like this and says no word, this is completely unproffesional

Offline jwt

  • Administrator
  • Sr. Member
  • *****
  • Posts: 322
  • Karma: +87/-14
    • View Profile
Re: Snap 27 Oct 10:31:57 CDT - broken IPSEC status
« Reply #10 on: November 21, 2015, 11:20:59 am »
Ermal,

I had not named you, but since you outed yourself, I will respond.

I wasn't blaming you for the memory leak, that's due an interaction with how strongswan uses it's "built-in" printf extensions and the implementation of same in FreeBSD's libc.

Moving the printf extensions from "builtin" (libc) to vstr stopped (nearly all of) the leak, but, due to the way the strongswan plugin system is architected, the SMP interface is not compatible with the vstr library.

Several times I tried to get you to replace the SMP interface with VICI, and each time you abjectly refused.  This despite the demonstrated need, because SMP had been deprecated in-favor of VICI, and the technical debt incurred in maintaining a set of custom patches to a port.

When we finally undertook the work to replace the SMP plugin, it took less than two days to a full solution.  In the process, we reduced the technical debt of the project, because we now need fewer custom patches to the Strongswan port in FreeBSD.

The "logs" have not been erased as you accuse.  We put the formerly discrete patches (and patches on patches) on a branch in a copy of the FreeBSD 'src' and 'ports' trees.

In closing, a lot of the work you did here was good.  It was really your poor attitude, tendency to 'go missing' for extended periods and repeated instances of involving yourself in situations that presented a clear conflict of interest that catalyzed your dismissal.