NetFilter
[Top] [All Lists]

[PATCH 0/2] xt_u32 - match arbitrary bits and bytes of a packet

To: Netfilter Mailing List <netfilter@lists.netfilter.org>, Netfilter Developer Mailing List <netfilter-devel@lists.netfilter.org>, Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: [PATCH 0/2] xt_u32 - match arbitrary bits and bytes of a packet
From: Jan Engelhardt <jengelh@linux01.gwdg.de>
Date: Sat, 2 Jun 2007 23:46:46 +0200 (MEST)
Cc:
Delivered-to: sp-com-lists@consult.net
Delivered-to: netfilter-list1@securepoint.com
List-archive: </pipermail/netfilter>
List-help: <mailto:netfilter-request@lists.netfilter.org?subject=help>
List-id: General discussion and user questions <netfilter.lists.netfilter.org>
List-post: <mailto:netfilter@lists.netfilter.org>
List-subscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=subscribe>
List-unsubscribe: <https://lists.netfilter.org/mailman/listinfo/netfilter>, <mailto:netfilter-request@lists.netfilter.org?subject=unsubscribe>
Sender: netfilter-bounces@lists.netfilter.org
Hello!


along comes xt_u32, a revamped ipt_u32,

    *   added ipv6 support since that seemed dead simple, given u32's 
        task. I would have even liked to unlock u32 for _all_ protocols, 
        but .family = AF_UNSPEC does not do the right thing right now, 
        but that's not so much a showstopper.

        And arptables seems miles away from using iptables modules. So
        AF_INET and AF_INET6 it is for now.

    *   Reduced the buffer size to 17 KB. I think that is quite ok since 
        I added an overflow check,  SHOULD THERE BE ANY device with an 
        MTU larger than our loopback masterpiece (16436 bytes).

        Are there such devices that support Megasuperjumboframes?
        The previous buffer size of 64 KB was probably the cutting edge,
        as a single IPv4 fragment/packet does not support more than that 
        anyway.


Questions, comments, blame, praise, please.
I'd like to get this merged so I do not have to maintain it out-of-tree.


        Jan
-- 


<Prev in Thread] Current Thread [Next in Thread>