Userspace packet queuing with libipq: ip_conntrack does not defragment?

Userspace packet queuing with libipq: ip_conntrack does not defragment?

[Michael Ransburg]

Hi all,

I'm using libipq to pass certain packets to my userspace application
on Fedora 6 / Kernel 2.6.21.1 and ipTables 1.3.5.

I do:
modprobe iptable_filter
modprobe ip_queue
modprobe ip_conntrack
iptables -A INPUT -p tcp -j QUEUE

Works fine. However, since ip_conntrack is loaded I would expect that
the packets are defragmented before they are passed to my userspace
appliation (as indicated here for example:
http://lists.netfilter.org/pipermail/netfilter/2002-May/034006.html).
This does not seem the case, i.e., the maximum size of the packets
which I get (through ->data_len) is 1500 bits.

The len parameter of the ipq_read method is well over 1500, as is the
buffer size.

Any suggestions what I'm doing wrong?

Many thanks,
Michael
-- 
icq: 71772353 | skype: daneel1409 | msn: mike@unfolded.com

Re: Userspace packet queuing with libipq: ip_conntrack does not defragment?

[Michael Ransburg]

> Any suggestions what I'm doing wrong?

A small update: I found out (through this presentation:
http://ants.iis.sinica.edu.tw/linux_summer_school/Connection%20Tracking.ppt#262,5,Slide
5) that defragmentation is only available in the prerouting and output
chains. I therefore changed my iptables rule to OUTPUT, but I'm
getting the same result, i.e., maximum packet sizes of 1500.

Any hints are appreciated.

Thanks,
Michael

-- 
icq: 71772353 | skype: daneel1409 | msn: mike@unfolded.com

Re: Userspace packet queuing with libipq: ip_conntrack does not defragment?

[Martijn Lievaart]

Michael Ransburg wrote:
> However, since ip_conntrack is loaded I would expect that
> the packets are defragmented before they are passed to my userspace
> appliation (as indicated here for example:
> http://lists.netfilter.org/pipermail/netfilter/2002-May/034006.html).
> This does not seem the case, i.e., the maximum size of the packets
> which I get (through ->data_len) is 1500 bits.
>
> The len parameter of the ipq_read method is well over 1500, as is the
> buffer size.

Do you actually have packets greater than 1500 bytes? That would mean 
you send over loopback, tokenring, etc, but NOT ethernet.

Maybe you are confusing datagram and packet fragmentation. Conntrack 
only defragments packets, not datagrams.

HTH,
M4

Userspace packet queuing with libipq: ip_conntrack does not defragment?

[Michael Ransburg]

> > This was indeed my misconception. I thought that conntrack would
> > reassemble IP datagrams into the original (single) TCP/IP datagram. I
> > would like to access and inspect the reassembled TCP/IP datagram on my
> > firewall/router. Can netfilter provide me with this, i.e., can it take
> > care of reassembling and fragmentation of (e.g.) TCP/IP datagrams?
> >
>
> Mu! Tcp uses streams. There is nothing to reassemble. Udp uses
> datagrams, but netfilter cannot (and should not) reassemble those.
>
> What are you trying to achieve in the first place?

Sorry for using the wrong terminology. Let's say I'm downloading a
video from a website (over HTTP/TCP/IP). What I see is that each
picture of the video is send as a single TCP/IP packet (?) - usually
with a size of around 10 KB. This TCP/IP packet is fragmented
according to the MTU and therefore I see the following fragments on
the wire:
Fragment 1: <Ethernet header><IP header><TCP header>application data
Fragment 2: <Ethernet header><IP header>application data
Fragment 3: <Ethernet header><IP header>application data
…

On my router/firewall I would like to inspect the video picture as a
whole. In my current (windows) application I have to reassemble the
fragments manually into the original TCP/IP packet. I hoped that
netfilter would make my life easier by performing the reassembling for
me (and potentially also the recalculation of the checksum(s) if the
video picture is changed).

Is there support in netfilter for this kind of stuff? I've googled
quite a bit and there seem to be discussions indicating that NAT is
doing that (http://lists.netfilter.org/pipermail/netfilter/2001-January/006915.html)...?

Many thanks again for your help,
Michael
--
icq: 71772353 | skype: daneel1409 | msn: mike@unfolded.com

Re: Userspace packet queuing with libipq: ip_conntrack does not defragment?

[Jan Engelhardt]

On May 9 2007 18:34, Martijn Lievaart wrote:
> Michael Ransburg wrote:
>> However, since ip_conntrack is loaded I would expect that
>> the packets are defragmented before they are passed to my userspace
>> appliation (as indicated here for example:
>> http://lists.netfilter.org/pipermail/netfilter/2002-May/034006.html).
>> This does not seem the case, i.e., the maximum size of the packets
>> which I get (through ->data_len) is 1500 bits.
>> 
>> The len parameter of the ipq_read method is well over 1500, as is the
>> buffer size.
>
> Do you actually have packets greater than 1500 bytes? That would mean you send
> over loopback, tokenring, etc, but NOT ethernet.

Gigabit ethernet allows for 9000-byte jumbo frames.

> Maybe you are confusing datagram and packet fragmentation. Conntrack only
> defragments packets, not datagrams.


	Jan
--