netgraph mkpeer and connect failures with ng_ipfw and ng_nat

[Julian Elischer]

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?