Kevin Sanders wrote:
On 12/22/06, Brooks Davis <[EMAIL PROTECTED]> wrote:
On Fri, Dec 22, 2006 at 12:43:29PM -0300, Fabr?cio Barros Cabral wrote:
> Hello everybody!
>
> I'm developing a network application which needs *to intercept* a
packet
> (not just *copy* a packet, like libpcap does), move this packet into my
> application (userland), do some checking in the packet and according
> with some heuristics, the application may change the payload and
> re-inject the modified packet into the network. Note that sometimes,
> I'll change the payload, drop the packet or just let it go.
>
> So, how can a I do that in FreeBSD? I can use 6.1, 7.1, any version.
The feature you're looking for is divert(4) sockets. You use IPFW to
decide which packets to divert to userland and can reinject them as
needed.
-- Brooks
I'm actually working on something with a similar need. How would this
perform compared to a kld module that is using the pfil(9) framework? I'm
looking to support very high bandwidth networks, with 400mpbs or more over
gig ethernet. In my case I'm looking at HTTP requests and not necessarily
every packet once I've done what I need to the actual http request/headers.
Obviousely, if I grow or shrink the HTTP request, I then have to "massage"
the seq/ack to keep the two talking, but this is only for a small
percentage
of the sessions, and I didn't want to be hit with a kernel -> user space ->
kernel transition for every packet.
Divert is designed for diverting from the IP layer, to the user layer
for processing (and returning the packet to be sent out/in). It is fast
enough for most WAN applications.
I use patches to allow me to divert from a bridge (Ethernet layer)
but it's still going to userland.
If you want to work in the kernel, then take a look at netgraph.
(check the daemonnews article by Archie Cobbs (google is your friend),
and man 4 netgraph).
It allows you to divert from the Ethernet layer to an arbitrary
in-kernel module for processing in any way you want.
Look at ng_sample.c to get a skeleton netgraph node that you can
use as a starting point for your own processing.
Netgraph does have (due to its generality) some overhead,
but the code you write to make a netgraph node will be the same
code you would write for any other kernel mode processor so
getting it running as a netgraph node will allow you to test it
quickly. You should then test its performance. If this is fast
enough (netgraph CAN be fast so you should test this) then you
are done. If you are not getting enough performance, then you will need
to write a custom 'pfil' module that puts itself on the pfil
processing list. If you still need more peroformance then I suggest you
need to start hacking if_ethersubr.c itself and that is not the best
way to go for mainatanability.
It's also important for me to be able to see the ethernet header, because I
running in a transparent bridge, and sometimes need to send a redirect back
to the client making the request, and it needs to appear to come from the
server the client is talking to. Yes, this is a content filter.
I actually have all this working, and I'm currently working on the user
space "service" which talks to the kernel module and makes decisions to
allow, block, or modify the request. Performance is pretty good, but my 10
years of Win32 development experience didn't prepare me for UNIX kernel
module development!
I have the same thing.. which is why I divert from ethernet layer.
There are some tricks that can be done to really speat that up however..
for example you only need to look at the first syn packet.. all the rest
don't need to be looked at or diverted.
Kevin
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
