From: Xavier Claude <contact@xavierclaude.be>
To: netfilter-devel@vger.kernel.org
Subject: [PATCH conntrack-tools] Typo in contrackd-conf manpage
Date: Wed, 09 Jul 2025 18:39:20 +0000 [thread overview]
Message-ID: <3365321.aeNJFYEL58@kashyyk> (raw)
Hello,
I've found a few typos in the conntrackd.conf.5 manpage.
I hope it's the right mailing list for this kind of report.
-- >8 --
Fixes some small typos on the conf file manpage. Acknowledegement is not a typo
per se, but I've uniformized the spelling to use the same everywhere.
Signed-off-by: Xavier Claude <contact@xavierclaude.be>
---
conntrackd.conf.5 | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/conntrackd.conf.5 b/conntrackd.conf.5
index 50d7b98..fbb75e3 100644
--- a/conntrackd.conf.5
+++ b/conntrackd.conf.5
@@ -84,7 +84,7 @@ In this synchronization mode you may configure
\fBResendQueueSize\fP,
.TP
.BI "ResendQueueSize <value>"
Size of the resend queue (in objects). This is the maximum number of objects
-that can be stored waiting to be confirmed via acknoledgment.
+that can be stored waiting to be confirmed via acknowledgment.
If you keep this value low, the daemon will have less chances to recover
state-changes under message omission. On the other hand, if you keep this
value
high, the daemon will consume more memory to store dead objects.
@@ -120,8 +120,8 @@ Default is 60 seconds.
.TP
.BI "ACKWindowSize <value>"
-Set the acknowledgement window size. If you decrease this value, the number
of
-acknowlegdments increases. More acknowledgments means more overhead as
+Set the acknowledgment window size. If you decrease this value, the number of
+acknowledgments increases. More acknowledgments means more overhead as
\fBconntrackd(8)\fP has to handle more control messages. On the other hand,
if
you increase this value, the resend queue gets more populated. This results
in
more overhead in the queue releasing.
@@ -334,7 +334,7 @@ fault-tolerance. In case of doubt, use it.
This section indicates to \fBconntrackd(8)\fP to use UDP as transport
mechanism between nodes of the firewall cluster.
-As in the \fBMulticast\fP configuration, you may especify several fail-over
+As in the \fBMulticast\fP configuration, you may specify several fail-over
dedicated links using the \fIDefault\fP keyword.
Example:
@@ -407,7 +407,7 @@ If you combine this transport with the \fBNOTRACK\fP mode,
it becomes reliable.
The TCP transport protocol can be configured in exactly the same way as
the \fBUDP\fP transport protocol.
-As in the \fBMulticast\fP configuration, you may especify several fail-over
+As in the \fBMulticast\fP configuration, you may specify several fail-over
dedicated links using the \fIDefault\fP keyword.
Example:
--
2.50.0
next reply other threads:[~2025-07-09 18:39 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-09 18:39 Xavier Claude [this message]
2025-07-09 20:10 ` [PATCH conntrack-tools] Typo in contrackd-conf manpage Florian Westphal
2025-07-09 20:23 ` Xavier Claude
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3365321.aeNJFYEL58@kashyyk \
--to=contact@xavierclaude.be \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.