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.
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
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.
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
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.