Date: Thu, 14 Jan 2010 16:22:31 -0800 From: Julian Elischer <julian@elischer.org> To: Erik Klavon <erikk@berkeley.edu> Cc: freebsd-net@freebsd.org Subject: Re: netgraph mkpeer and connect failures with ng_ipfw and ng_nat Message-ID: <4B4FB547.8000202@elischer.org> In-Reply-To: <20100114224635.GA27139@malcolm.berkeley.edu> References: <20100114224635.GA27139@malcolm.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Erik Klavon wrote:
>
> Here are the hooks for one ng_nat(4) node of interest. At the time I
> obtained this information, this node was working correctly. Everything
> in this output looks correct.
>
> sudo ngctl show ipfw:202182138
> Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: 2
> Local hook Peer name Peer type Peer ID Peer hook
> ---------- --------- --------- ------- ---------
> in ipfw ipfw 00005a83 102182138
> out ipfw ipfw 00005a83 202182138
>
> sudo ngctl msg ipfw:102182138 listredirects
> Rec'd response "listredirects" (10) from "[62ee]:":
> Args: { total_count=1 redirects=[ { id=1 local_addr=10.10.118.43 alias_addr=136.152.182.138 proto=259 description="Static NAT" } ] }
>
> Running show on ipfw:102174202, I see that this hook is pointing to
> the above ng_nat(4) node WirelessNAT2182138.
can you show that output?
>
> sudo ngctl show ipfw:102174202
> Name: WirelessNAT2182138 Type: nat ID: 000062ee Num hooks: 2
> Local hook Peer name Peer type Peer ID Peer hook
> ---------- --------- --------- ------- ---------
> in ipfw ipfw 00005a83 102182138
> out ipfw ipfw 00005a83 202182138
>
> But WirelessNAT2182138 has no record of a hook102174202. Somehow, two
> hooks used to refer to what should be two different NAT sessions are
> pointing to the same ng_nat(4) object (i.e. one session). If I run
> shutdown on ipfw:102174202, WirelessNAT2182138 goes away. Given the
> above calls to ngctl(8), I don't know what is causing these two separate
> hooks to refer to the same ng_nat(4) object.
you might name the ipfw nodes to make the output clearer.
I have not looked at the ipfw node type much but it is possible
that is suffers from races.
Especially in the face of ipfw rule changes.
have you tried adding small delays (sleep 0.5) betwenn the calls by
the way?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B4FB547.8000202>