netfilter hook not working with fragments

netfilter hook not working with fragments

[Michael Varga]

Hi,

I wrote a NF_IP_PRE_ROUTING hook to capture packets
for an IPSec implimentation.

Is there a way to make netfilter assemble fragments before=20
recieving them in my netfilter hook?

thanks
Mike

netfilter hook not working with fragments

[Michael Varga]

Hi,

I wrote a NF_IP_PRE_ROUTING hook to capture packets
for an IPSec implimentation.

Is there a way to make netfilter assemble fragments before=20
recieving them in my netfilter hook?

thanks
Mike

Re: netfilter hook not working with fragments

[Pablo Neira]

Michael Varga wrote:

>Hi,
>
>I wrote a NF_IP_PRE_ROUTING hook to capture packets
>for an IPSec implimentation.
>
>Is there a way to make netfilter assemble fragments before=20
>recieving them in my netfilter hook?
>  
>

If you use a kernel 2.4, you won't see any fragments since netfilter 
assembles them before hitting NF_IP_PRE_PREROUTING. On the other hand, 
if your box runs a kernel 2.6,  assemble them by yourself. Have a look 
at skb_linearize. Previously check that it's non linear with 
skb_is_non_linear.

http://lxr.linux.no/source/include/linux/skbuff.h#L1041
http://lxr.linux.no/source/include/linux/skbuff.h#L655

Since you get packets from interrupt context, make sure you pass the 
GFP_ATOMIC flag to skb_linearize.

--
Pablo

Packet mangle issues with retransmissions

[Scott MacKay]

Hiyas,
   Working under 2.4.x (at least 2.4.20 from RH9) I
think I have an issue that I am starting to unravel
with regards to TCP and packet mangling.  I am not
sure if this is something fixed or more of a 'don't do
that'...
In mangling a TCP packet (POSTROUTING), I adjust the
size of the packet, reducing the overall length as I
mangle the contents.
This normally works all happy skipper like.  A big
issue comes in, though, on retransmission.  If the
system decided it needs to resend the packet, I get
something nasty happening.
   Looking at the packet contents on resent via
ethereal, I see the initial portion of the packet
containing my changes, but then the system seems to
fill the contents back up to the full MTU!  That would
be fine, except it retains my packet alteration.

I would think the problem I am seeing is 1 of 2
things.
First, maybe skbuff dataspace comes from the tcp
buffer's allocation.  this would mean any mangling
performed on a packet affects the actual real buffer,
not some memory copy.
Secondly, if it is a private space, then it would seem
that the resend mechanism tries to insure the packet
is full, so adds on to fill to MTU, not memcpying over
anything it *thinks* is already sent.
Either way, it seems bad becase a POSTROUING packet
mangling will see it's mangled data on a tcp retrasmit
which I am not sure is intended.
So I guess my questions, for those who are
enlightened...
1.  is skbuff data private or can it point into some
tcp structure's allocated space?
2.  Could this be something fixed already (and no, I
canot go to 2.6 just yet)
3.  Is there a way to tell skbuff that the data is
'dirty', namely that it should try and reackage the
whole thing on retransmit?
Thanks for any info!!

Scott

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com