Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.2-2 i686) Description of problem: I've insmod'd cipcb with cipe_debug=0 and the logging is *still* excessive. The logging needs to be a bit more intelligent. How reproducible: Always Steps to Reproduce: 1. modprobe cipcb cipe_debug=0 2. start up a cipe connection 3. use it a while 4. grep cip /var/log/messages 5. grep cip /var/log/messages | wc -l 6. cat /var/log/messages | wc -l 7. note the percentage Actual Results: 360/471 considering that 357 of those lines were "... cerberus ciped-cb[nnnn]: keepalive timeout", this is a bit much Expected Results: Don't log timeouts when the number of timeouts allowed is -1 This alone would go a long way, but a lot of the logging is unnecessary cipe_debug should default to zero--most people don't need to know about every packet sent and recieved. Additional info:
My error... if I insmod cipcb cipe_debug=0, it'll have no debug output. Problem is that this isn't default. Putting options cipcb cipe_debug=0 in /etc/modules.conf fixes it, but this should be done by the cipe package (or the source should be patched to make it default.)
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. Note that any bug still open against Red Hat Linux on will be closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
I've moved on to Fedora Core long ago. I no longer have a need for cipe and would probably set up IPSEC in its place anyway, so I don't mind if you close this bug as DEFERRED/WONTFIX/CANTFIX or whatever is appropriate. Thanks for the followup, even if it's been sitting in your hopper for 5 years. :-)
Hmm, I don't think we're going to be changing this at this point. Given that the package is gone in current releases, closing as won't-fix.