On Wednesday, November 30, 2011 19:28:15 Pablo Neira Ayuso wrote:

On Wed, Nov 30, 2011 at 04:27:26PM +0100, Patrick McHardy wrote:

quoted

On 11/28/2011 10:36 AM, Hans Schillstrom wrote:

quoted

quoted

If you don't want to use conntrack in your setup and you want to handle
fragments, then you have to configure HMARK to calculate the hashing
based on the network addresses. If you want to fully support fragments,
then enable conntrack and you can configure HMARK to calculate the
hashing based on network address + transport bits.

Fix this by removing the fragmentation handling, then assume that
people can select between two hashing configuration for HMARK. One
based for network address which is fragment-safe, one that uses the
transport layer information, that requires conntrack. Otherwise, I
don't see a sane way to handle this situation.

Correct me if I'm wrong here,
If conntrack is enabled hmark don't see the packet until it is reassembled and
in that case the fragmentation header is removed.

So, with conntrack HMARK will operate on full packets not fragments
without conntrack ports will not be used on any fragment

Correct.

To complete what Patrick said. They are collected but not linearized.
That's why you have to use skb_header_pointer.

OK, thanks
I'll will do that.

quoted

You don't necessarily need conntrack for defragmentation though,
we've moved defragmentation to a seperate module for TPROXY. You
can depend on that and get defragmentation without full
connection tracking.

Indeed, I missed this. That way you can skip conntrack but solving the
broken fragments handling.

In a cluster with inputs on many different blades (with a Virtual IP address) you can
receive the fragments on different blades and in that case there should not be any
defrag in that node. HMARK will just produce the same fw-mark for all fragments.

In our case defrag will happens in next hop i.e. before going into IPVS.

As mention earlier, this needs to be documented better.
I will add this to the man page.

Thanks
Hans