ipfw on just inbound and not outbound

[Ian Smith]

On Sun, 24 May 2015 11:24:45 +0300, Alexander V. Chernikov wrote:
 > 23.05.2015, 03:58, "hiren panchasara" <hiren at strugglingcoder.info>:
 > > On 05/21/15 at 02:05P, hiren panchasara wrote:
 > >>  On 05/21/15 at 12:42P, hiren panchasara wrote:
 > >>>  Getting back to this now to see if I can avoid ipfw on outgoing packets.
 > >>>
 > >>>  @@ -500,7 +507,7 @@ ipfw_hook(int onoff, int pf)
 > >>>          hook_func = (pf == AF_LINK) ? ipfw_check_frame : ipfw_check_packet;
 > >>>
 > >>>          (void) (onoff ? pfil_add_hook : pfil_remove_hook)
 > >>>  -           (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh);
 > >>>  +           (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh);
 > >>>
 > >>>          return 0;
 > >>>  }
 > >>>
 > >>>  Should this do the right thing? I'll report back once I test this patch.
 > >>  I am still seeing ipfw_chk() getting called in my iperf test. Now, if I
 > >>  also remove PFIL_IN, i.e if I do:
 > >>  -           (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh);
 > >>  +           (hook_func, NULL, PFIL_WAITOK, pfh);
 > >>
 > >>  I don't see ipfw_chk() getting triggered.
 > >>
 > >>  Somehow incoming traffic is affecting the outgoing traffic?
 > >
 > > It seems I screwed up something in testing and the following does seem to do the
 > > right thing:
 > >
 > > -           (hook_func, NULL, PFIL_IN | PFIL_OUT | PFIL_WAITOK, pfh);
 > > +           (hook_func, NULL, PFIL_IN | PFIL_WAITOK, pfh);
 > >
 > > I confirmed this with pmcstat callgraphs that ipfw_chk() is not getting
 > > called in OUT direction.
 > >
 > > Any thoughts on this? Is this something that can be upstreamed with a
 > > sysctl knob if there is interest?

 > Unfortunately, I've missed most of the thread.
 > First of all, just calling ipfw hook should not be so costy - I can 
 > believe in 5% in 8/9/10, but the reason should be not ipfw, but 
 > rwlock which is used ti protect ruleset.
 > HEAD version should behave better (we observe something like 1% 
 > overhead on 10+mpps rate) since it uses rmlock.

That's certainly a big improvement.

 > Being able to attach/detach appropriate L3 hooks is really a good 
 > idea, however the better (but not easier way) would be to implement 
 > something like `pfilctl' utility which would be able to 
 > control/disable/reorder hooks on particular filtering points (pf 
 > before ipfw or vice versa). This stuff would also help to convert 
 > some of the current L2 processing code to pfil (like 
 > BPF,lagg,netgraph input hooks in eher_input)

Well ipfw already may be seeing L2 traffic via net.link.ether.ipfw; is 
that already separate from the L3 pfil hooks?  I haven't followed pfil.

The more generic way to link and order hooks sounds like a better idea 
than needing to mess with ipfw (or pf, or anything) to accomplish that.

cheers, Ian (FWIW)