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

Re: PF or BPF



I'm not sure I'd do it in that way. I'm thinking if BPF provided stateful
inspection is would be
more useful.

Asking for stateful inspection in bpf(4) is like wanting a carburettor
for a pushbike. You might be able to shoehorn it in there, but it won't
be pretty, will ruin its simplicity and probably won't be much use.

Yeah this would be something in addition to BPF and not to alter BPF. I like the simple
functionary but I think it would be hard to management complex rule (s). The language is
a little clunky. Just think is doing something when you have to check protocol #, source and dst address
and TCP flags. I guess the fact that BPF branches only forward does both simplify and limit its scope.



FFPF is a different approach, and they (rightly) didn't use bpf(4) as
their base implementation. Some of their ideas look pretty good, but
if you are interested in pursuing them the you had probably best do it
in parallel to the existing bpf(4) infrastructure.

-d


I'm at the survey stage. I know about a number of efforts which apply BPF-like
technology to lots of applications. As you say, FFPF has some neat ideas, and it is
efficient (context switching, number of copies) , more scalability (BPF is a little clunky no
loops) and able to handle more complex situations. Its even has backward compatibility of BPF.
However, It doesn't support BSD that as far as I know, I hadn't looked that closely for that reason.
Might in interesting if its no overly dependent some linux kernel feature.



Respectfully, Tony Sterrett

tonys_(_at_)_sterrett_(_dot_)_net
Consultant in Open Source Software, featuring OpenBSD and Linux.
www.sterrett.net
(858) 433-1467 San Diego
(408) 705-2135 San Jose