[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bpf "filter drop" implementation (please test dhclient)

* Reyk Floeter <reyk_(_at_)_vantronix_(_dot_)_net> [2005-11-03 21:17]:
> let me explain the functionality of FILDROP somewhat better: we use bpf
> filters to sort out unwanted packets. in addition to the classic bpf
> filter interface (see bpf(4)), the "filter drop" option will mark any
> filtered packets to drop them before they actually _enter_ the network
> stack (i.e., in ether_input()). so if you run dhclient with the
> attached patch, your system won't receive any traffic except DHCP
> packets while requesting a new IP address. this is some kind of a very
> basic "application layer" packet filter interface, but it isn't
> related to pf.

well, the real point of this diff is that it fixes a real problem :)

dhc* uses bpf to grab packets from the stack, and then asnwers usin bpf 
again. but the packet that, say, dhcpd just grabbed via bpf still 
traverses the stack further up. there we finally discover that there is 
nothing listening on the destination port and the stack sends an ICMP 
error message. so for one dhcp request we send one reply _and_ one icmp 
error message. fortunately it seems like nothing gets confused by that, 
but it is still incorrect.

the first idea canacar and I had to fix that, and that he implemented 
around c2k4, was to let the bpf calls from within the network drivers 
have a return value, and drop the mbuf when it returned !0. that worked 
somewhat - but it broke some cases with dhcpd on bridges at least. I 
then had the idea to use an unused bit in an already existant flag 
bitfield in the mbuf header to indicate that the packet should be 
dropped later (so that above cases would still work). that is what reyk 
implemented now.

sometimes things take a little longer :)