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

netfilter 01/05: fix tuple inversion for Node information request

[Patrick McHardy]

commit 21c87b35badcae15fe48335bd5985c9fb3d152c8
Author: Eric Leblond <eric@inl.fr>
Date:   Mon Feb 9 14:24:43 2009 +0100

    netfilter: fix tuple inversion for Node information request
    
    The patch fixes a typo in the inverse mapping of Node Information
    request. Following draft-ietf-ipngwg-icmp-name-lookups-09, "Querier"
    sends a type 139 (ICMPV6_NI_QUERY) packet to "Responder" which answer
    with a type 140 (ICMPV6_NI_REPLY) packet.
    
    Signed-off-by: Eric Leblond <eric@inl.fr>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
index c455cf4..114a92e 100644
--- a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
+++ b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
@@ -49,8 +49,8 @@ static bool icmpv6_pkt_to_tuple(const struct sk_buff *skb,
 static const u_int8_t invmap[] = {
 	[ICMPV6_ECHO_REQUEST - 128]	= ICMPV6_ECHO_REPLY + 1,
 	[ICMPV6_ECHO_REPLY - 128]	= ICMPV6_ECHO_REQUEST + 1,
-	[ICMPV6_NI_QUERY - 128]		= ICMPV6_NI_QUERY + 1,
-	[ICMPV6_NI_REPLY - 128]		= ICMPV6_NI_REPLY +1
+	[ICMPV6_NI_QUERY - 128]		= ICMPV6_NI_REPLY + 1,
+	[ICMPV6_NI_REPLY - 128]		= ICMPV6_NI_QUERY +1
 };
 
 static bool icmpv6_invert_tuple(struct nf_conntrack_tuple *tuple,

netfilter 02/05: nf_conntrack_ipv6: don't track ICMPv6 negotiation message

[Patrick McHardy]

commit 422b9bbd900dbb89dd3afaa8180daed4dae69eea
Author: Eric Leblond <eric@inl.fr>
Date:   Mon Feb 9 14:24:44 2009 +0100

    netfilter: nf_conntrack_ipv6: don't track ICMPv6 negotiation message
    
    This patch removes connection tracking handling for ICMPv6 messages
    related to Stateless Address Autoconfiguration, MLD, and MLDv2. They
    can not be tracked because they are massively using multicast (on
    pre-defined address). But they are not invalid and should not be
    detected as such.
    
    Signed-off-by: Eric Leblond <eric@inl.fr>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
index 114a92e..c323643 100644
--- a/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
+++ b/net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c
@@ -53,6 +53,17 @@ static const u_int8_t invmap[] = {
 	[ICMPV6_NI_REPLY - 128]		= ICMPV6_NI_QUERY +1
 };
 
+static const u_int8_t noct_valid_new[] = {
+	[ICMPV6_MGM_QUERY - 130] = 1,
+	[ICMPV6_MGM_REPORT -130] = 1,
+	[ICMPV6_MGM_REDUCTION - 130] = 1,
+	[NDISC_ROUTER_SOLICITATION - 130] = 1,
+	[NDISC_ROUTER_ADVERTISEMENT - 130] = 1,
+	[NDISC_NEIGHBOUR_SOLICITATION - 130] = 1,
+	[NDISC_NEIGHBOUR_ADVERTISEMENT - 130] = 1,
+	[ICMPV6_MLD2_REPORT - 130] = 1
+};
+
 static bool icmpv6_invert_tuple(struct nf_conntrack_tuple *tuple,
 				const struct nf_conntrack_tuple *orig)
 {
@@ -178,6 +189,7 @@ icmpv6_error(struct net *net, struct sk_buff *skb, unsigned int dataoff,
 {
 	const struct icmp6hdr *icmp6h;
 	struct icmp6hdr _ih;
+	int type;
 
 	icmp6h = skb_header_pointer(skb, dataoff, sizeof(_ih), &_ih);
 	if (icmp6h == NULL) {
@@ -194,6 +206,15 @@ icmpv6_error(struct net *net, struct sk_buff *skb, unsigned int dataoff,
 		return -NF_ACCEPT;
 	}
 
+	type = icmp6h->icmp6_type - 130;
+	if (type >= 0 && type < sizeof(noct_valid_new) &&
+	    noct_valid_new[type]) {
+		skb->nfct = &nf_conntrack_untracked.ct_general;
+		skb->nfctinfo = IP_CT_NEW;
+		nf_conntrack_get(skb->nfct);
+		return NF_ACCEPT;
+	}
+
 	/* is not error message ? */
 	if (icmp6h->icmp6_type >= 128)
 		return NF_ACCEPT;

netfilter 03/05: ctnetlink: allow changing NAT sequence adjustment in creation

[Patrick McHardy]

commit 028cf4480479685d7768bfdd6afe3f7bf9545b39
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Feb 9 14:25:52 2009 +0100

    netfilter: ctnetlink: allow changing NAT sequence adjustment in creation
    
    This patch fixes an inconsistency in the current ctnetlink code
    since NAT sequence adjustment bit can only be updated but not set
    in the conntrack entry creation.
    
    This patch is used by conntrackd to successfully recover newly
    created entries that represent connections with helpers and NAT
    payload mangling.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index c32a7e8..9051bb4 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -1215,6 +1215,16 @@ ctnetlink_create_conntrack(struct nlattr *cda[],
 		}
 	}
 
+#ifdef CONFIG_NF_NAT_NEEDED
+	if (cda[CTA_NAT_SEQ_ADJ_ORIG] || cda[CTA_NAT_SEQ_ADJ_REPLY]) {
+		err = ctnetlink_change_nat_seq_adj(ct, cda);
+		if (err < 0) {
+			rcu_read_unlock();
+			goto err;
+		}
+	}
+#endif
+
 	if (cda[CTA_PROTOINFO]) {
 		err = ctnetlink_change_protoinfo(ct, cda);
 		if (err < 0) {

netfilter 04/05: ctnetlink: fix echo if not subscribed to any multicast group

[Patrick McHardy]

commit 8f0613c03d2bb8ab39f6e21ff555026dce503179
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Mon Feb 9 14:26:52 2009 +0100

    netfilter: ctnetlink: fix echo if not subscribed to any	multicast group
    
    This patch fixes echoing if the socket that has sent the request to
    create/update/delete an entry is not subscribed to any multicast
    group. With the current code, ctnetlink would not send the echo
    message via unicast as nfnetlink_send() would be skip.
    
    Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/netfilter/nf_conntrack_netlink.c b/net/netfilter/nf_conntrack_netlink.c
index 9051bb4..cb78aa0 100644
--- a/net/netfilter/nf_conntrack_netlink.c
+++ b/net/netfilter/nf_conntrack_netlink.c
@@ -434,7 +434,7 @@ static int ctnetlink_conntrack_event(struct notifier_block *this,
 	} else
 		return NOTIFY_DONE;
 
-	if (!nfnetlink_has_listeners(group))
+	if (!item->report && !nfnetlink_has_listeners(group))
 		return NOTIFY_DONE;
 
 	skb = alloc_skb(NLMSG_GOODSIZE, GFP_ATOMIC);
@@ -1502,7 +1502,8 @@ static int ctnetlink_expect_event(struct notifier_block *this,
 	} else
 		return NOTIFY_DONE;
 
-	if (!nfnetlink_has_listeners(NFNLGRP_CONNTRACK_EXP_NEW))
+	if (!item->report &&
+	    !nfnetlink_has_listeners(NFNLGRP_CONNTRACK_EXP_NEW))
 		return NOTIFY_DONE;
 
 	skb = alloc_skb(NLMSG_GOODSIZE, GFP_ATOMIC);

netfilter 05/05: xt_sctp: sctp chunk mapping doesn't work

[Patrick McHardy]

commit 3c0994f8a7864e1d1de3cefbcf715bfde5b2a41a
Author: Qu Haoran <haoran.qu@6wind.com>
Date:   Mon Feb 9 15:35:43 2009 +0100

    netfilter: xt_sctp: sctp chunk mapping doesn't work
    
    When user tries to map all chunks given in argument, kernel
    works on a copy of the chunkmap, but at the end it doesn't
    check the copy, but the orginal one.
    
    Signed-off-by: Qu Haoran <haoran.qu@6wind.com>
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Patrick McHardy <kaber@trash.net>

diff --git a/net/netfilter/xt_sctp.c b/net/netfilter/xt_sctp.c
index e223cb4..a189ada 100644
--- a/net/netfilter/xt_sctp.c
+++ b/net/netfilter/xt_sctp.c
@@ -105,7 +105,7 @@ match_packet(const struct sk_buff *skb,
 
 	switch (chunk_match_type) {
 	case SCTP_CHUNK_MATCH_ALL:
-		return SCTP_CHUNKMAP_IS_CLEAR(info->chunkmap);
+		return SCTP_CHUNKMAP_IS_CLEAR(chunkmapcopy);
 	case SCTP_CHUNK_MATCH_ANY:
 		return false;
 	case SCTP_CHUNK_MATCH_ONLY:

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 :)