By default the ipsec-tools are built with "--enable-stats" option. This is a compile time option, which results in the logs being filled with the statistics about how much data was encrypted in the given time. --enable-stats enable statistics logging function May 11 20:15:09 server racoon: alg_oakley_hmacdef_one(hmac_sha1 size=36): 0.000014 May 11 20:15:09 server racoon: alg_oakley_hmacdef_one(hmac_sha1 size=36): 0.000013 May 11 20:15:09 server racoon: alg_oakley_encdef_encrypt(aes klen=256 size=64): 0.000009 May 11 20:15:15 server racoon: alg_oakley_hmacdef_one(hmac_sha1 size=36): 0.000017 May 11 20:15:15 server racoon: alg_oakley_encdef_encrypt(aes klen=256 size=64): 0.000035 May 11 20:15:15 server racoon: alg_oakley_encdef_decrypt(aes klen=256 size=64): 0.000039 May 11 20:15:15 server racoon: alg_oakley_hmacdef_one(hmac_sha1 size=36): 0.000028 May 11 20:15:15 server racoon: alg_oakley_encdef_decrypt(aes klen=256 size=64): 0.000039 On a busy gateway/server it produces huge volumes of useless data. There is no option to disable it during the run time, unless you recompile without this option. e.g. of the amount of log entries server # grep "May 10" racoon.log | wc -l 123307 server current # grep "May 10" racoon.log | grep alg_oakley | wc -l 122932 besides, in the ebuild file, this option is mistakenly (i hope:) specified twice --enable-frag \ --enable-stats \ <<<< --enable-fastquit \ --enable-stats \ <<<< --enable-adminport \ Reproducible: Always Expected Results: either omit the option from the ebuild, or make it selectable by the USEFLAG. Here is the discussion on the ipsec-tools devel list regarding the stats option http://article.gmane.org/gmane.network.ipsec.tools.devel/1347
Robert, cc'ing you since you are the last person with a non-trivial commit.
+1 Also, can we get this line removed from /etc/conf.d/racoon: RACOON_OPTS="-4" When I build with the ipv6 USE flag I epxect to get IPv6. Less then two years now until IPv4 exhaustion.
(In reply to comment #2) > +1 > > Also, can we get this line removed from /etc/conf.d/racoon: > > RACOON_OPTS="-4" > > > When I build with the ipv6 USE flag I epxect to get IPv6. Less then two years > now until IPv4 exhaustion. > I even don't know what that should be useful for. I'd guess to enable IPv4 only but does racoon support such a flag at all? # /etc/init.d/racoon start * Loading ipsec policies from /etc/ipsec.conf. The result of line 3: File exists. * Starting racoon ... /usr/sbin/racoon: invalid option -- '4' usage: racoon [-BdFv] [-a (port)] [-f (file)] [-l (file)] [-p (port)] -B: install SA to the kernel from the file specified by the configuration file. -d: debug level, more -d will generate more debug message. -C: dump parsed config file. -L: include location in debug messages -F: run in foreground, do not become daemon. -v: be more verbose -a: port number for admin port. -f: pathname for configuration file. -l: pathname for log file. -p: port number for isakmp (default: 500). -P: port number for NAT-T (default: 4500). * start-stop-daemon: failed to start `/usr/sbin/racoon' [ !! ] * ERROR: racoon failed to start
This trivial to fix bug has been open almost 2 years! Can we get it fixed please?
Congratulations, you made it! By today, this bug has completed it's second year of existence. Note that it didn't get any more complicated or obscure in it's time being - all the old, trivial to fix and highly annoying bug we got to know two years ago. Good luck for the next two years, and keep on annoying us as you did so well until today!
I recently adopted this package and bumped to 0.8.0. I added a USE flag for stats which addresses the point of the bug, so I'm closing this one. As for comment #2, its still in there but I have no objections to removing RACOON_OPTS="-4". Usually its up to the user to mess with the conf.d but I see your point. Please test by removing it with 0.8.0 and let me know if there are any issues --- I know its trivial, but I don't use ipsec with ipv6 and I'd like to proceed cautiously with an important package I just adopted. As for comment #5, I can assure you that I am a responsive maintainer. I was shocked when I came across such an important package that was left without a maintainer.
(In reply to comment #6) > As for comment #2, its still in there but I have no objections to removing > RACOON_OPTS="-4". Usually its up to the user to mess with the conf.d but I see > your point. Please test by removing it with 0.8.0 and let me know if there are > any issues --- I know its trivial, but I don't use ipsec with ipv6 and I'd like > to proceed cautiously with an important package I just adopted. IMHO it shouldn't hurt as long as it's commented out by default. Problem is, the option (along with -6) only exists when having IPv6 support compiled into racoon. So in fact only those users could make use of it which obviously seem to not want it due to their choice of USE flags. ;) > As for comment #5, I can assure you that I am a responsive maintainer. I was > shocked when I came across such an important package that was left without a > maintainer. Good to know, although it makes me a bit sad seeing this bug finally die after it has survived for almost three years now. :)
I'm testing now. So far so good. Thanks so much! Next: how do we get this in stable?
(In reply to comment #8) > I'm testing now. So far so good. Thanks so much! > > Next: how do we get this in stable? 30 days in the tree without major bugs open. Wait about a month and then open a stablereq. In the mean time, I have to at least address an issue in the build system where it looks for a header file in /usr/src/linux/include/linux rather than /usr/include/linux. In fact the whole ebuild makes the dangerous assumption that the running kernel = the kernel source + config in /usr/src/linux. This is seldom the case as people update/change kernels often.
