netfilter 00/05: netfilter fixes

netfilter 00/05: netfilter fixes

[Patrick McHardy]

Hi Dave,

the following five patches contain netfilter fixes for 2.6.29:

- a patch from Eric Leblond to fix tuple inversion for IPv6 Node Information
  Requests in IPv6 conntrack

- a patch from Eric Leblond to ignore ICMPv6 negotiation messages in IPv6
  conntrack since it can't track multicast communication. This prevents
  those packets from getting marked as INVALID.

- two ctnetlink fixes from Pablo to fix a small inconsistency in conntrack
  creation wrt. NAT sequence number adjustment settings and to fix netlink
  unicast delivery of responses messages.

- a patch from Qu Haoran to fix the SCTP match when matching on the entire
  chunkmap.

Please apply or pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git

Thanks!


 net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c |   25 ++++++++++++++++++++++-
 net/netfilter/nf_conntrack_netlink.c           |   15 ++++++++++++-
 net/netfilter/xt_sctp.c                        |    2 +-
 3 files changed, 37 insertions(+), 5 deletions(-)

Eric Leblond (2):
      netfilter: fix tuple inversion for Node information request
      netfilter: nf_conntrack_ipv6: don't track ICMPv6 negotiation message

Pablo Neira Ayuso (2):
      netfilter: ctnetlink: allow changing NAT sequence adjustment in creation
      netfilter: ctnetlink: fix echo if not subscribed to any	multicast group

Qu Haoran (1):
      netfilter: xt_sctp: sctp chunk mapping doesn't work

Re: netfilter 00/05: netfilter fixes

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Mon,  9 Feb 2009 17:39:27 +0100 (MET)

> Please apply or pull from:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git

I was going to pull from your tree and take it like that, but when I
pulled I got 5 real changes and 50 merges with net-2.6, yikes! :-)

If there was one or two merge changesets in there, I would have
taken it.  But anything more than that for a tree containing
5 bug fixes is excessive.

I'll apply these as patches, but I really do want to be able to
pull from your trees so please try to provide a cleaner tree
next time.

Thanks!

Re: netfilter 00/05: netfilter fixes

[Patrick McHardy]

David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon,  9 Feb 2009 17:39:27 +0100 (MET)
> 
>> Please apply or pull from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git
> 
> I was going to pull from your tree and take it like that, but when I
> pulled I got 5 real changes and 50 merges with net-2.6, yikes! :-)

Ugh sorry, thats happening automatically, but it usually doesn't show
up since it should be fast forwards. I'll have a look at what went
wrong.

> If there was one or two merge changesets in there, I would have
> taken it.  But anything more than that for a tree containing
> 5 bug fixes is excessive.
> 
> I'll apply these as patches, but I really do want to be able to
> pull from your trees so please try to provide a cleaner tree
> next time.

I'll make sure of it, sorry.

Re: netfilter 00/05: netfilter fixes

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Mon, 09 Feb 2009 23:47:07 +0100

> David Miller wrote:
> > From: Patrick McHardy <kaber@trash.net>
> > Date: Mon,  9 Feb 2009 17:39:27 +0100 (MET)
> > 
> >> Please apply or pull from:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git
> > I was going to pull from your tree and take it like that, but when I
> > pulled I got 5 real changes and 50 merges with net-2.6, yikes! :-)
> 
> Ugh sorry, thats happening automatically, but it usually doesn't show
> up since it should be fast forwards. I'll have a look at what went
> wrong.

I think you got a change into your tree locally, this went via net-2.6
and thereafterwards it started using merges.  But that's just a guess.

> > If there was one or two merge changesets in there, I would have
> > taken it.  But anything more than that for a tree containing
> > 5 bug fixes is excessive.
> > I'll apply these as patches, but I really do want to be able to
> > pull from your trees so please try to provide a cleaner tree
> > next time.
> 
> I'll make sure of it, sorry.

Want some suggestions for work flow? :-)

1) For net-2.6 just clone Linus's tree, pull net-2.6 once as it is
   right now, then leave it alone.

   Periodically sync your origin (which is Linus's tree) via
   "git fetch origin".  This just grabs the objects.

   Then you can just go "git request-pull origin $(GIT_URL)" and
   it'll just work.

   Since the likelyhood for conflicts in the net-2.6 tree with
   your netfilter work is incredibly unlikely, doing a merge
   should never be necessary.  But if it is just go
   "git pull origin".

2) For net-next-2.6 use net-next-2.6 as your "origin" (you can change
   this in .git/config), conflicts are more likely so every once in
   a while a "git pull origin" will be necessary.

If that doesn't work out or feel comfortable for you, that's
fine.

Re: netfilter 00/05: netfilter fixes

[Patrick McHardy]

David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 09 Feb 2009 23:47:07 +0100
> 
>> David Miller wrote:
>>> From: Patrick McHardy <kaber@trash.net>
>>> Date: Mon,  9 Feb 2009 17:39:27 +0100 (MET)
>>>
>>>> Please apply or pull from:
>>>>
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git
>>> I was going to pull from your tree and take it like that, but when I
>>> pulled I got 5 real changes and 50 merges with net-2.6, yikes! :-)
>> Ugh sorry, thats happening automatically, but it usually doesn't show
>> up since it should be fast forwards. I'll have a look at what went
>> wrong.
> 
> I think you got a change into your tree locally, this went via net-2.6
> and thereafterwards it started using merges.  But that's just a guess.

Yes, probably, although I really never commit to my mirrored trees.
It might have something to do with my disk dying last week and the
restore I did :)

> Want some suggestions for work flow? :-)
> 
> 1) For net-2.6 just clone Linus's tree, pull net-2.6 once as it is
>    right now, then leave it alone.
> 
>    Periodically sync your origin (which is Linus's tree) via
>    "git fetch origin".  This just grabs the objects.
> 
>    Then you can just go "git request-pull origin $(GIT_URL)" and
>    it'll just work.
> 
>    Since the likelyhood for conflicts in the net-2.6 tree with
>    your netfilter work is incredibly unlikely, doing a merge
>    should never be necessary.  But if it is just go
>    "git pull origin".
> 
> 2) For net-next-2.6 use net-next-2.6 as your "origin" (you can change
>    this in .git/config), conflicts are more likely so every once in
>    a while a "git pull origin" will be necessary.
> 
> If that doesn't work out or feel comfortable for you, that's
> fine.

I'll try that, maybe starting with net-2.6 since that tree is
easier to maintain for me. My workflow is quite out of sync
with modern git commands, some of my scripts are still adapted
from bitkeeper times :)

Re: netfilter 00/05: netfilter fixes

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Tue, 10 Feb 2009 00:36:06 +0100

> My workflow is quite out of sync with modern git commands, some of
> my scripts are still adapted from bitkeeper times :)

You poor thing, I should buy you some beer :-)

But to be honest I had a caveman like mentality about
using GIT and it took me a long time to get to the
current way I do things:

1) Dark ages:

	Fresh git clone, add patches, push to Linus.
	Repeat, rebasing every time.

2) Brain enabled:

	Stable git clone, used over and over again.

	After Linus pulls, remember HEAD and use that as
	base for next pull request.

	Pull in Linus's tree occaisionally when conflicts
	might be possible.

3) Full enlightenment:

	Stable git clone, used over and over again.

	Track Linus's tree using "git fetch origin"

	When conflicts are possible "git pull origin"

	All pull requests are sent using "origin" as
	the base.

Re: netfilter 00/05: netfilter fixes

[Patrick McHardy]

David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Tue, 10 Feb 2009 00:36:06 +0100
> 
>> My workflow is quite out of sync with modern git commands, some of
>> my scripts are still adapted from bitkeeper times :)
> 
> You poor thing, I should buy you some beer :-)
> 
> But to be honest I had a caveman like mentality about
> using GIT and it took me a long time to get to the
> current way I do things:
> 
> 1) Dark ages:
> 
> 	Fresh git clone, add patches, push to Linus.
> 	Repeat, rebasing every time.
> 
> 2) Brain enabled:
> 
> 	Stable git clone, used over and over again.
> 
> 	After Linus pulls, remember HEAD and use that as
> 	base for next pull request.
> 
> 	Pull in Linus's tree occaisionally when conflicts
> 	might be possible.
> 
> 3) Full enlightenment:
> 
> 	Stable git clone, used over and over again.
> 
> 	Track Linus's tree using "git fetch origin"
> 
> 	When conflicts are possible "git pull origin"
> 
> 	All pull requests are sent using "origin" as
> 	the base.

I'll skip step 2 and will send a perfect pull request soon :)

netfilter 00/05: netfilter fixes

[Patrick McHardy]

Hi Dave,

the following patches fix a couple of netfilter bugs:

- fix for use of unintialized values in the recent match compat proc handling
  from Jan Engelhardt

- Removal of an incorrect TProxy dependency on conntrack from
  Laszlo Attila Toth

- Addition of missing netlink options for the DCCP conntrack protocol,
  from Pablo

- Fix for a conntrack protocol registration regression in 2.6.30-rc from myself

- A fix for bridge-netfilter re-fragmentation of VLAN packets defragmented
  by conntrack from Saikiran Madugula

Please apply or pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git

Thanks!


 include/linux/netfilter/nfnetlink_conntrack.h |    1 +
 net/bridge/br_netfilter.c                     |   10 +++++++++-
 net/netfilter/Kconfig                         |    4 ++--
 net/netfilter/nf_conntrack_proto_dccp.c       |   16 +++++++++++++++-
 net/netfilter/nf_conntrack_proto_udplite.c    |    1 +
 net/netfilter/xt_recent.c                     |    9 ++++-----
 6 files changed, 32 insertions(+), 9 deletions(-)

Jan Engelhardt (1):
      netfilter: xt_recent: fix stack overread in compat code

Laszlo Attila Toth (1):
      netfilter: Kconfig: TProxy doesn't depend on NF_CONNTRACK

Pablo Neira Ayuso (1):
      netfilter: nf_ct_dccp: add missing role attributes for DCCP

Patrick McHardy (1):
      netfilter: nf_ct_dccp/udplite: fix protocol registration error

hummerbliss@gmail.com (1):
      netfilter: bridge: allow fragmentation of VLAN packets traversing a bridge

netfilter 01/05: bridge: allow fragmentation of VLAN packets traversing a bridge

[Patrick McHardy]

commit c197facc8ea08062f8f949aade6a33649ee06771
Author: hummerbliss@gmail.com <hummerbliss@gmail.com>
Date:   Mon Apr 20 17:12:35 2009 +0200

    netfilter: bridge: allow fragmentation of VLAN packets traversing a bridge
    
    br_nf_dev_queue_xmit only checks for ETH_P_IP packets for fragmenting but not
    VLAN packets. This results in dropping of large VLAN packets. This can be
    observed when connection tracking is enabled. Connection tracking re-assembles
    fragmented packets, and these have to re-fragmented when transmitting out. Also,
    make sure only refragmented packets are defragmented as per suggestion from
    Patrick McHardy.
    
    Signed-off-by: Saikiran Madugula <hummerbliss@gmail.com>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 3953ac4..e4a418f 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -788,15 +788,23 @@ static unsigned int br_nf_local_out(unsigned int hook, struct sk_buff *skb,
 	return NF_STOLEN;
 }
 
+#if defined(CONFIG_NF_CONNTRACK_IPV4) || defined(CONFIG_NF_CONNTRACK_IPV4_MODULE)
 static int br_nf_dev_queue_xmit(struct sk_buff *skb)
 {
-	if (skb->protocol == htons(ETH_P_IP) &&
+	if (skb->nfct != NULL &&
+	    (skb->protocol == htons(ETH_P_IP) || IS_VLAN_IP(skb)) &&
 	    skb->len > skb->dev->mtu &&
 	    !skb_is_gso(skb))
 		return ip_fragment(skb, br_dev_queue_push_xmit);
 	else
 		return br_dev_queue_push_xmit(skb);
 }
+#else
+static int br_nf_dev_queue_xmit(struct sk_buff *skb)
+{
+        return br_dev_queue_push_xmit(skb);
+}
+#endif
 
 /* PF_BRIDGE/POST_ROUTING ********************************************/
 static unsigned int br_nf_post_routing(unsigned int hook, struct sk_buff *skb,

netfilter 02/05: nf_ct_dccp/udplite: fix protocol registration error

[Patrick McHardy]

commit 5ff482940f5aa2cdc3424c4a8ea94b9833b2af5f
Author: Patrick McHardy <kaber@trash.net>
Date:   Fri Apr 24 15:37:44 2009 +0200

    netfilter: nf_ct_dccp/udplite: fix protocol registration error
    
    Commit d0dba725 (netfilter: ctnetlink: add callbacks to the per-proto
    nlattrs) changed the protocol registration function to abort if the
    to-be registered protocol doesn't provide a new callback function.
    
    The DCCP and UDP-Lite IPv6 protocols were missed in this conversion,
    add the required callback pointer.
    
    Reported-and-tested-by: Steven Jan Springl <steven@springl.ukfsn.org>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/netfilter/nf_conntrack_proto_dccp.c b/net/netfilter/nf_conntrack_proto_dccp.c
index 50dac8d..5411d63 100644
--- a/net/netfilter/nf_conntrack_proto_dccp.c
+++ b/net/netfilter/nf_conntrack_proto_dccp.c
@@ -777,6 +777,7 @@ static struct nf_conntrack_l4proto dccp_proto6 __read_mostly = {
 	.print_conntrack	= dccp_print_conntrack,
 #if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE)
 	.to_nlattr		= dccp_to_nlattr,
+	.nlattr_size		= dccp_nlattr_size,
 	.from_nlattr		= nlattr_to_dccp,
 	.tuple_to_nlattr	= nf_ct_port_tuple_to_nlattr,
 	.nlattr_tuple_size	= nf_ct_port_nlattr_tuple_size,
diff --git a/net/netfilter/nf_conntrack_proto_udplite.c b/net/netfilter/nf_conntrack_proto_udplite.c
index 4614696..0badedc 100644
--- a/net/netfilter/nf_conntrack_proto_udplite.c
+++ b/net/netfilter/nf_conntrack_proto_udplite.c
@@ -204,6 +204,7 @@ static struct nf_conntrack_l4proto nf_conntrack_l4proto_udplite6 __read_mostly =
 	.error			= udplite_error,
 #if defined(CONFIG_NF_CT_NETLINK) || defined(CONFIG_NF_CT_NETLINK_MODULE)
 	.tuple_to_nlattr	= nf_ct_port_tuple_to_nlattr,
+	.nlattr_tuple_size	= nf_ct_port_nlattr_tuple_size,
 	.nlattr_to_tuple	= nf_ct_port_nlattr_to_tuple,
 	.nla_policy		= nf_ct_port_nla_policy,
 #endif

netfilter 03/05: Kconfig: TProxy doesn't depend on NF_CONNTRACK

[Patrick McHardy]

commit 4b0706624930dc75c3b0d0df463d89759ef7de29
Author: Laszlo Attila Toth <panther@balabit.hu>
Date:   Fri Apr 24 16:55:25 2009 +0200

    netfilter: Kconfig: TProxy doesn't depend on NF_CONNTRACK
    
    Signed-off-by: Laszlo Attila Toth <panther@balabit.hu>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig
index 2329c5f..881203c 100644
--- a/net/netfilter/Kconfig
+++ b/net/netfilter/Kconfig
@@ -275,6 +275,8 @@ config NF_CT_NETLINK
 	help
 	  This option enables support for a netlink-based userspace interface
 
+endif # NF_CONNTRACK
+
 # transparent proxy support
 config NETFILTER_TPROXY
 	tristate "Transparent proxying support (EXPERIMENTAL)"
@@ -290,8 +292,6 @@ config NETFILTER_TPROXY
 
 	  To compile it as a module, choose M here.  If unsure, say N.
 
-endif # NF_CONNTRACK
-
 config NETFILTER_XTABLES
 	tristate "Netfilter Xtables support (required for ip_tables)"
 	default m if NETFILTER_ADVANCED=n

netfilter 04/05: nf_ct_dccp: add missing role attributes for DCCP

[Patrick McHardy]

commit 71951b64a5a87c09eb6fde59ce51aaab2fdaeab2
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Fri Apr 24 16:58:41 2009 +0200

    netfilter: nf_ct_dccp: add missing role attributes for DCCP
    
    This patch adds missing role attribute to the DCCP type, otherwise
    the creation of entries is not of any use.
    
    The attribute added is CTA_PROTOINFO_DCCP_ROLE which contains the
    role of the conntrack original tuple.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/include/linux/netfilter/nfnetlink_conntrack.h b/include/linux/netfilter/nfnetlink_conntrack.h
index 29fe9ea..1a865e4 100644
--- a/include/linux/netfilter/nfnetlink_conntrack.h
+++ b/include/linux/netfilter/nfnetlink_conntrack.h
@@ -100,6 +100,7 @@ enum ctattr_protoinfo_tcp {
 enum ctattr_protoinfo_dccp {
 	CTA_PROTOINFO_DCCP_UNSPEC,
 	CTA_PROTOINFO_DCCP_STATE,
+	CTA_PROTOINFO_DCCP_ROLE,
 	__CTA_PROTOINFO_DCCP_MAX,
 };
 #define CTA_PROTOINFO_DCCP_MAX (__CTA_PROTOINFO_DCCP_MAX - 1)
diff --git a/net/netfilter/nf_conntrack_proto_dccp.c b/net/netfilter/nf_conntrack_proto_dccp.c
index 5411d63..8e757dd 100644
--- a/net/netfilter/nf_conntrack_proto_dccp.c
+++ b/net/netfilter/nf_conntrack_proto_dccp.c
@@ -633,6 +633,8 @@ static int dccp_to_nlattr(struct sk_buff *skb, struct nlattr *nla,
 	if (!nest_parms)
 		goto nla_put_failure;
 	NLA_PUT_U8(skb, CTA_PROTOINFO_DCCP_STATE, ct->proto.dccp.state);
+	NLA_PUT_U8(skb, CTA_PROTOINFO_DCCP_ROLE,
+		   ct->proto.dccp.role[IP_CT_DIR_ORIGINAL]);
 	nla_nest_end(skb, nest_parms);
 	read_unlock_bh(&dccp_lock);
 	return 0;
@@ -644,6 +646,7 @@ nla_put_failure:
 
 static const struct nla_policy dccp_nla_policy[CTA_PROTOINFO_DCCP_MAX + 1] = {
 	[CTA_PROTOINFO_DCCP_STATE]	= { .type = NLA_U8 },
+	[CTA_PROTOINFO_DCCP_ROLE]	= { .type = NLA_U8 },
 };
 
 static int nlattr_to_dccp(struct nlattr *cda[], struct nf_conn *ct)
@@ -661,11 +664,21 @@ static int nlattr_to_dccp(struct nlattr *cda[], struct nf_conn *ct)
 		return err;
 
 	if (!tb[CTA_PROTOINFO_DCCP_STATE] ||
-	    nla_get_u8(tb[CTA_PROTOINFO_DCCP_STATE]) >= CT_DCCP_IGNORE)
+	    !tb[CTA_PROTOINFO_DCCP_ROLE] ||
+	    nla_get_u8(tb[CTA_PROTOINFO_DCCP_ROLE]) > CT_DCCP_ROLE_MAX ||
+	    nla_get_u8(tb[CTA_PROTOINFO_DCCP_STATE]) >= CT_DCCP_IGNORE) {
 		return -EINVAL;
+	}
 
 	write_lock_bh(&dccp_lock);
 	ct->proto.dccp.state = nla_get_u8(tb[CTA_PROTOINFO_DCCP_STATE]);
+	if (nla_get_u8(tb[CTA_PROTOINFO_DCCP_ROLE]) == CT_DCCP_ROLE_CLIENT) {
+		ct->proto.dccp.role[IP_CT_DIR_ORIGINAL] = CT_DCCP_ROLE_CLIENT;
+		ct->proto.dccp.role[IP_CT_DIR_REPLY] = CT_DCCP_ROLE_SERVER;
+	} else {
+		ct->proto.dccp.role[IP_CT_DIR_ORIGINAL] = CT_DCCP_ROLE_SERVER;
+		ct->proto.dccp.role[IP_CT_DIR_REPLY] = CT_DCCP_ROLE_CLIENT;
+	}
 	write_unlock_bh(&dccp_lock);
 	return 0;
 }

netfilter 05/05: xt_recent: fix stack overread in compat code

[Patrick McHardy]

commit 37e55cf0ceb8803256bf69a3e45bd668bf90b76f
Author: Jan Engelhardt <jengelh@medozas.de>
Date:   Fri Apr 24 17:05:21 2009 +0200

    netfilter: xt_recent: fix stack overread in compat code
    
    Related-to: commit 325fb5b4d26038cba665dd0d8ee09555321061f0
    
    The compat path suffers from a similar problem. It only uses a __be32
    when all of the recent code uses, and expects, an nf_inet_addr
    everywhere. As a result, addresses stored by xt_recents were
    filled with whatever other stuff was on the stack following the be32.
    
    Signed-off-by: Jan Engelhardt <jengelh@medozas.de>
    
    With a minor compile fix from Roman.
    
    Reported-and-tested-by: Roman Hoog Antink <rha@open.ch>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/netfilter/xt_recent.c b/net/netfilter/xt_recent.c
index 791e030..eb0ceb8 100644
--- a/net/netfilter/xt_recent.c
+++ b/net/netfilter/xt_recent.c
@@ -474,7 +474,7 @@ static ssize_t recent_old_proc_write(struct file *file,
 	struct recent_table *t = pde->data;
 	struct recent_entry *e;
 	char buf[sizeof("+255.255.255.255")], *c = buf;
-	__be32 addr;
+	union nf_inet_addr addr = {};
 	int add;
 
 	if (size > sizeof(buf))
@@ -506,14 +506,13 @@ static ssize_t recent_old_proc_write(struct file *file,
 		add = 1;
 		break;
 	}
-	addr = in_aton(c);
+	addr.ip = in_aton(c);
 
 	spin_lock_bh(&recent_lock);
-	e = recent_entry_lookup(t, (const void *)&addr, NFPROTO_IPV4, 0);
+	e = recent_entry_lookup(t, &addr, NFPROTO_IPV4, 0);
 	if (e == NULL) {
 		if (add)
-			recent_entry_init(t, (const void *)&addr,
-					  NFPROTO_IPV4, 0);
+			recent_entry_init(t, &addr, NFPROTO_IPV4, 0);
 	} else {
 		if (add)
 			recent_entry_update(t, e);

Re: netfilter 00/05: netfilter fixes

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Fri, 24 Apr 2009 17:44:01 +0200 (MEST)

> Please apply or pull from:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git

Pulled, thanks Patrick.

It would be nice to see this fixed:

  CHECK   include/linux/netfilter (57 files)
/home/davem/src/GIT/net-2.6/usr/include/linux/netfilter/xt_LED.h:6: found __[us]{8,16,32,64} type without #include <linux/types.h>
  LD      vmlinux

Thanks!

Re: netfilter 00/05: netfilter fixes

[Patrick McHardy]

David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Fri, 24 Apr 2009 17:44:01 +0200 (MEST)
> 
>> Please apply or pull from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git
> 
> Pulled, thanks Patrick.
> 
> It would be nice to see this fixed:
> 
>   CHECK   include/linux/netfilter (57 files)
> /home/davem/src/GIT/net-2.6/usr/include/linux/netfilter/xt_LED.h:6: found __[us]{8,16,32,64} type without #include <linux/types.h>

Appologies for my silence over the past week, holidays and a swine
cold kept me away from the computer .)

I've queued a fix for this, thanks.

netfilter 00/05: netfilter fixes

[Patrick McHardy]

Hi Dave,

the following patches fix a couple of bugs in netfilter and IPVS:

- a fix for a crash triggered by fragmentes received by bridge netfilter being
  combined with fragments received on non-bridge devices from myself

- a fix for IPVS synchronization on connection close from Xiaotian Feng

- a fix for use of uninitialized fields in IPVS from Simon Horman

- a patch to document the minimal required iptables version from Jan Engelhardt

I'll also push the fragment fix to stable (forgot to add CC before committing)
once it hits mainline.

Please apply or pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master

Thanks!


 Documentation/Changes                          |    2 ++
 include/net/ip.h                               |    1 +
 include/net/ipv6.h                             |    8 ++++++++
 include/net/netfilter/ipv6/nf_conntrack_ipv6.h |    2 +-
 net/ipv4/netfilter/nf_defrag_ipv4.c            |   21 +++++++++++++++++----
 net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c |   19 +++++++++++++++++--
 net/ipv6/netfilter/nf_conntrack_reasm.c        |    7 ++++---
 net/ipv6/reassembly.c                          |    5 ++++-
 net/netfilter/ipvs/ip_vs_core.c                |    1 +
 net/netfilter/ipvs/ip_vs_ctl.c                 |    4 ++++
 10 files changed, 59 insertions(+), 11 deletions(-)

Jan Engelhardt (1):
      netfilter: xtables: document minimal required version

Patrick McHardy (2):
      ipv6: reassembly: use seperate reassembly queues for conntrack and local delivery
      netfilter: fix crashes in bridge netfilter caused by fragment jumps

Simon Horman (1):
      ipvs: zero usvc and udest

Xiaotian Feng (1):
      ipvs: fix synchronization on connection close

Re: netfilter 00/05: netfilter fixes

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Tue, 15 Dec 2009 17:14:27 +0100 (MET)

> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master

Pulled, thanks a lot Patrick.

netfilter 00/05: netfilter fixes

[Patrick McHardy]

Hi Dave,

following are the bugfixes for nf_conntrack discussed over the past
days, as well as a bugfix for the use of pointer to a local variable
outside the scope of the variable:

- a fix for use count initialization of the "untracked" conntrack,
  fixing freeing of memory in the data section

- a patch for per netns conntrack cache pointers to fix issues
  with SLAB_DESTROY_BY_RCU

- a patch to disable conntrack expect hash size modification at runtime

- a patch for xtables to fix out of scope usage of a local variable

- a patch to fix conntrack hash resizing with multiple namespaces by
  moving the hashsize into the per netns data

Please apply or pull from:

git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master

Please note: I forgot to add "Cc: stable@kernel.org" to two of these
patches and manually added it to the patch files, so I'd appreciate
if you could apply the patches manually instead of pulling from the
git tree this time.

Thanks!


 include/net/netns/conntrack.h                      |    3 +
 include/net/netns/ipv4.h                           |    1 +
 net/ipv4/netfilter/arp_tables.c                    |    4 +-
 net/ipv4/netfilter/ip_tables.c                     |    4 +-
 net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c     |    2 +-
 .../netfilter/nf_conntrack_l3proto_ipv4_compat.c   |    4 +-
 net/ipv4/netfilter/nf_nat_core.c                   |   22 ++--
 net/ipv6/netfilter/ip6_tables.c                    |    4 +-
 net/netfilter/nf_conntrack_core.c                  |  116 +++++++++++---------
 net/netfilter/nf_conntrack_expect.c                |    4 +-
 net/netfilter/nf_conntrack_helper.c                |    2 +-
 net/netfilter/nf_conntrack_netlink.c               |    2 +-
 net/netfilter/nf_conntrack_standalone.c            |    7 +-
 13 files changed, 93 insertions(+), 82 deletions(-)

Alexey Dobriyan (2):
      netfilter: nf_conntrack: restrict runtime expect hashsize modifications
      netfilter: xtables: compat out of scope fix

Eric Dumazet (1):
      netfilter: nf_conntrack: per netns nf_conntrack_cachep

Patrick McHardy (2):
      netfilter: nf_conntrack: fix memory corruption with multiple namespaces
      netfilter: nf_conntrack: fix hash resizing with namespaces

Re: netfilter 00/05: netfilter fixes

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Mon,  8 Feb 2010 18:10:26 +0100 (MET)

> Please apply or pull from:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
> 
> Please note: I forgot to add "Cc: stable@kernel.org" to two of these
> patches and manually added it to the patch files, so I'd appreciate
> if you could apply the patches manually instead of pulling from the
> git tree this time.

Ok, I'll apply these by hand.

Thanks Patrick.

Re: netfilter 00/05: netfilter fixes

[Patrick McHardy]

David Miller wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon,  8 Feb 2010 18:10:26 +0100 (MET)
> 
>> Please apply or pull from:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
>>
>> Please note: I forgot to add "Cc: stable@kernel.org" to two of these
>> patches and manually added it to the patch files, so I'd appreciate
>> if you could apply the patches manually instead of pulling from the
>> git tree this time.
> 
> Ok, I'll apply these by hand.

Thanks Dave. I plan to submit a first batch of patches queued for
net-next-2.6 soon, however these fixes introduced a large number
of conflicts. If you could merge net-2.6 into net-next-2.6 I'll
resolve them and send a pull request.

Thanks!

Re: netfilter 00/05: netfilter fixes

[Jan Engelhardt]

On Tuesday 2010-02-09 18:33, Patrick McHardy wrote:

>David Miller wrote:
>> From: Patrick McHardy <kaber@trash.net>
>> Date: Mon,  8 Feb 2010 18:10:26 +0100 (MET)
>> 
>>> Please apply or pull from:
>>>
>>> git://git.kernel.org/pub/scm/linux/kernel/git/kaber/nf-2.6.git master
>>>
>>> Please note: I forgot to add "Cc: stable@kernel.org" to two of these
>>> patches and manually added it to the patch files, so I'd appreciate
>>> if you could apply the patches manually instead of pulling from the
>>> git tree this time.
>> 
>> Ok, I'll apply these by hand.
>
>Thanks Dave. I plan to submit a first batch of patches queued for
>net-next-2.6 soon, however these fixes introduced a large number
>of conflicts. If you could merge net-2.6 into net-next-2.6 I'll
>resolve them and send a pull request.

Ah that is a good opportunity then to rebase my pending -next patches, 
to reduce conflicts you would have to solve when merging things after 
the conflict resolution.

Re: netfilter 00/05: netfilter fixes

[David Miller]

From: Patrick McHardy <kaber@trash.net>
Date: Tue, 09 Feb 2010 18:33:17 +0100

> If you could merge net-2.6 into net-next-2.6 I'll
> resolve them and send a pull request.

Done.

Re: netfilter 00/05: netfilter fixes

[Patrick McHardy]

Jan Engelhardt wrote:
> On Tuesday 2010-02-09 18:33, Patrick McHardy wrote:
> 
>> Thanks Dave. I plan to submit a first batch of patches queued for
>> net-next-2.6 soon, however these fixes introduced a large number
>> of conflicts. If you could merge net-2.6 into net-next-2.6 I'll
>> resolve them and send a pull request.
> 
> Ah that is a good opportunity then to rebase my pending -next patches, 
> to reduce conflicts you would have to solve when merging things after 
> the conflict resolution.

I've merged the current net-next tree and pushed it out.