Why ipfw didn't filter neither log DHCP packets ?

[Julian Elischer]

On 1/5/15 9:51 PM, Luigi Rizzo wrote:
> On Mon, Jan 5, 2015 at 2:41 PM, Olivier Cochard-Labbé <olivier at cochard.me>
> wrote:
>
>>
>> I believe that when Luigi says "that acts before the firewall has a chance
>> to see the packets", he was not speaking of the RC script order, but about
>> the FreeBSD network stack layer order.
>> Do you confirm Luigi ?
>>
>>
> ​correct, it's not a matter of time but of placement
> of the modules in the stack.
>
> injection through bpf goes just above the
> device driver, so there is no chance to see
> bpf-generated packets.
> For incoming traffic, bpf sees a copy, so the
> original still goes through the stack,
> but if you want to see it with ipfw you should
> probably enable layer2 firewalling.
the ordering of the various "special" packet intercepts has always 
been an 'unsolved problem'.
Packets may be intercepted by several different agents in the 
networkng code. There are (at least):
bpf/tcpdump
divert
netgraph
ipfw/pf/ipf
if_bridge
vlan handling

And maybe others I didn't think of in the 20 seconds it took to write 
this.
Each of these has an equivalent outgoing injection point as well.
It is possible to make arguments for several different orders in which 
packets should hit these.

For example:
It makes perfect sense for tcpdump to see everything on the wire
regardless of what else is going on, however it may also make
sense to filter what gets to dhclient.  Unfortunately, they both use
the same way of getting packets.
Maybe the answer is to change dhclient to use a different
method.  When it was originally done only bpf existed.


> cheers
> luigi
> _______________________________________________
> freebsd-ipfw at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
> To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe at freebsd.org"
>
>
>