* injecting packets from QUEUE handler
@ 2005-01-07 5:39 Mike Carlton
2005-01-07 8:48 ` Maarten Wijnants
0 siblings, 1 reply; 2+ messages in thread
From: Mike Carlton @ 2005-01-07 5:39 UTC (permalink / raw)
To: netfilter
I've got an application where I need to inspect up to the first 2 data
packets of a new HTTP connection before deciding whether to pass or
alter the connection data (in particular, I need to see the initial
HTML data and some servers will send HTTP headers in one packet and
data in the next).
I've setup a QUEUE target so that I can do this all in user space. It
is easy enough to cache the contents of the first packet (if we need
to inspect the second for this particular connection) and return
NF_DROP.
The question is how to best handle the case when we inspect the second
packet and decide everything is fine so it is time to send the saved
first packet and the current second.
I'm planning on just NF_ACCEPTing the second packet, then using a
PF_PACKET socket to re-inject the contents of the first packet.
Is there a cleaner way to do this? I'll have to take care of various
corner cases (ie. the packets get dropped or duplicated before
reaching us). I'll let the clients deal with the out of order packet
arrivals that we cause.
thanks,
--mike
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: injecting packets from QUEUE handler
2005-01-07 5:39 injecting packets from QUEUE handler Mike Carlton
@ 2005-01-07 8:48 ` Maarten Wijnants
0 siblings, 0 replies; 2+ messages in thread
From: Maarten Wijnants @ 2005-01-07 8:48 UTC (permalink / raw)
To: Mike Carlton, netfilter
Hello Mike,
This is an interesting question. I am doing a similar thing in my libipq
userspace application. My approach to the described situation is to issue
NF_DROP for the packets and subsequently send them out in the userspace
application with a UDP socket (because I am only doing this for UDP
traffic). This works fine, but the drawback is that this way the source IP
and port are set to the IP and port of the machine running the userspace
application. What I do to fix this, is to QUEUE the packets on the OUTPUT
hook and there I replace the source IP and port of the sent out packets with
their original values.
As said, this approach works fine for me, but I am interested to know if
there are other possibilities (e.g. using the NAT table to set the source IP
and port back to their original values).
Kind regards,
Maarten
----- Original Message -----
From: "Mike Carlton" <mikecarlton@gmail.com>
To: <netfilter@lists.netfilter.org>
Sent: Friday, January 07, 2005 6:39 AM
Subject: injecting packets from QUEUE handler
> I've got an application where I need to inspect up to the first 2 data
> packets of a new HTTP connection before deciding whether to pass or
> alter the connection data (in particular, I need to see the initial
> HTML data and some servers will send HTTP headers in one packet and
> data in the next).
>
> I've setup a QUEUE target so that I can do this all in user space. It
> is easy enough to cache the contents of the first packet (if we need
> to inspect the second for this particular connection) and return
> NF_DROP.
>
> The question is how to best handle the case when we inspect the second
> packet and decide everything is fine so it is time to send the saved
> first packet and the current second.
>
> I'm planning on just NF_ACCEPTing the second packet, then using a
> PF_PACKET socket to re-inject the contents of the first packet.
>
> Is there a cleaner way to do this? I'll have to take care of various
> corner cases (ie. the packets get dropped or duplicated before
> reaching us). I'll let the clients deal with the out of order packet
> arrivals that we cause.
>
> thanks,
> --mike
>
>
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2005-01-07 8:48 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-07 5:39 injecting packets from QUEUE handler Mike Carlton
2005-01-07 8:48 ` Maarten Wijnants
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox