From: Richard A Nelson <cowboy@cavein.org>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: netfilter@vger.kernel.org
Subject: Re: conntrack-tools rpc helper
Date: Wed, 26 Dec 2012 19:36:33 -0500 [thread overview]
Message-ID: <50DB9811.7040002@cavein.org> (raw)
In-Reply-To: <20121226224301.GA32453@1984>
On 12/26/2012 05:43 PM, Pablo Neira Ayuso wrote:
> Hi Richard,
Thanks for the quick, and on target note !
>
> {
> .name = rpc,
> .queuenum = 0,
> .l3protonum = 2,
> .l4protonum = 17,
> .priv_data_len = 16,
> .status = disabled,
> };
>
> Why disabled? conntrackd startup went fine, the nfct helper add
> went fine, what am I missing ?
> That means conntrackd did not configured the helper so far, so it
> remains dormant in the kernel.
>
> Did you add the corresponding Helper clause to conntrackd.conf?
>
> It should be something similar to what you can find under
> conntrack-tools/doc/helper/conntrackd.conf.
>
> Please, check /var/log/conntrackd.log (or custom path in case you set
> it). It should report some information regarding the helper
> configuration.
My confusion seemed to have been the requisite three part dance - even though
they're pretty well described in the docs.
1) Register helpers via nfct
2) Add iptables rules in -t raw (output & prerouting)
3) (Re)Start conntrackd
I now see:
# nfct helper list
{
.name = rpc,
.queuenum = 2,
.l3protonum = 2,
.l4protonum = 6,
.priv_data_len = 16,
.status = enabled,
};
{
.name = rpc,
.queuenum = 1,
.l3protonum = 2,
.l4protonum = 17,
.priv_data_len = 16,
.status = enabled,
};
I rebooted, and made sure things came back up in the same state... looking good.
>
> This was tested with NFSv3 running both Linux in the client and the
> server sides.
Perfect, then - there is a good chance this'll go... I'm still somewhat worried
about the fact that the RPC call is answered by a different machine than the
request was made to... but trial and error is called for now ;)
>
> I'd suggest to start by getting that "disabled" issue resolved first,
> then, move on to see what other problem you find.
Exactly, one down - and I have removed the old rules allowing arbitrary replies
from port 111, and things are working well on the server side (NFSv3 mounts work
fine).
Now, to see if I can coax the AIX box into booting again - otherwise I'll try
another Linux client behind the server.
Thanks again!
--
Rick Nelson
Life'll kill ya -- Warren Zevon
Then you'll be dead -- Life'll kill ya
prev parent reply other threads:[~2012-12-27 0:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-25 2:23 conntrack-tools rpc helper Richard A Nelson
2012-12-25 3:11 ` Richard A Nelson
2012-12-26 22:43 ` Pablo Neira Ayuso
2012-12-27 0:36 ` Richard A Nelson [this message]
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=50DB9811.7040002@cavein.org \
--to=cowboy@cavein.org \
--cc=netfilter@vger.kernel.org \
--cc=pablo@netfilter.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.