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: > > On 11/28/2011 10:36 AM, Hans Schillstrom wrote: > > >>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. > > > 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 -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
