Netfilter problem with new 2.4.22

Netfilter problem with new 2.4.22

[Diadon]

More new info about this problem.

When I get ipt_REJECT.c from 2.4.21 and replace ipt_REJECT.c in 2.4.22, 
problem has disappeared. So when I compare two files ipt_REJECT.c from 
different versions of kernel:

3a4
 >  * Added support for ICMP type-3-code-13 (Maciej Soltysiak). [RFC 1812]
35a37,76
 > static inline struct rtable *route_reverse(struct sk_buff *skb, int 
local)
 > {
 >       struct iphdr *iph = skb->nh.iph;
 >       struct dst_entry *odst;
 >       struct rt_key key = {};
 >       struct rtable *rt;
 >
 >       if (local) {
 >               key.dst = iph->saddr;
 >               key.src = iph->daddr;
 >               key.tos = RT_TOS(iph->tos);
 >
 >               if (ip_route_output_key(&rt, &key) != 0)
 >                       return NULL;
 >       } else {
 >               /* non-local src, find valid iif to satisfy
 >                * rp-filter when calling ip_route_input. */
 >               key.dst = iph->daddr;
 >               if (ip_route_output_key(&rt, &key) != 0)
 >                       return NULL;
 >
 >               odst = skb->dst;
 >               if (ip_route_input(skb, iph->saddr, iph->daddr,
 >                                  RT_TOS(iph->tos), rt->u.dst.dev) != 0) {
 >                       dst_release(&rt->u.dst);
 >                       return NULL;
 >               }
 >               dst_release(&rt->u.dst);
 >               rt = (struct rtable *)skb->dst;
 >               skb->dst = odst;
 >       }
 >
 >       if (rt->u.dst.error) {
 >               dst_release(&rt->u.dst);
 >               rt = NULL;
 >       }
 >
 >       return rt;
 > }
 >
66,69c107
<       /* Routing: if not headed for us, route won't like source */
<       if (ip_route_output(&rt, oldskb->nh.iph->saddr,
<                           local ? oldskb->nh.iph->daddr : 0,
<                           RT_TOS(oldskb->nh.iph->tos), 0) != 0)
---
 >       if ((rt = route_reverse(oldskb, local)) == NULL)
332a371,373
 >       case IPT_ICMP_ADMIN_PROHIBITED:
 >               send_unreach(*pskb, ICMP_PKT_FILTERED);
 >               break;




As I think problem in new new route_reverse function which called from 
tcp_reset() procedure

So any new ideas?


 > Subject:
 > Netfilter problem with new 2.4.22
 > From:
 > Diadon <diadon@isfera.ru>
 > Date:
 > Tue, 16 Sep 2003 14:22:37 +0400
 > To:
 > linux-kernel@vger.kernel.org

 > After installing 2.4.22
 > this chain doesn't work
 > $IPPROG -A OUTPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

 > On 2.4.21 all works fine
 > In tcpdump on 2.4.21:
 > 14:41:41.752557 somehost.auth > somehost1.32825: R 0:0(0) ack 
217583467 win 0 (DF)

 > In tcpdump on 2.4.22:
 > nothing.......


 > any ideas?

Re: Netfilter problem with new 2.4.22

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 968 bytes --]

Diadon wrote:

> > On 2.4.21 all works fine
> > In tcpdump on 2.4.21:
> > 14:41:41.752557 somehost.auth > somehost1.32825: R 0:0(0) ack 
> 217583467 win 0 (DF)
>
> > In tcpdump on 2.4.22:
> > nothing....... 


Hi Diadon,
the problem seems to be that a dst for local input doesn't carry pmtu 
information, the pmtu
is set by rt_set_nexthop which is skipped for local input. The packet is 
dropped by send_reset
because of this check:

        /* "Never happens" */
        if (nskb->len > nskb->dst->pmtu)
                goto free_nskb;

;)

I've attached two possible fixes for this. The first one restores 
behaviour from before the
routing changes for LOCAL_OUT, the other one removes the check since 
obviously
"Never happens" is not true anymore (and it is not an error). Another 
possibility would
be something like "if (nskb->dst->pmtu && nskb->len > nskb->dst->pmtu)  ..."
Someone from the coreteam should comment which solution is prefered.

Regards,
Patrick

[-- Attachment #2: x.diff --]
[-- Type: text/plain, Size: 1448 bytes --]

===== net/ipv4/netfilter/ipt_REJECT.c 1.13 vs edited =====
--- 1.13/net/ipv4/netfilter/ipt_REJECT.c	Fri Jul 25 23:15:41 2003
+++ edited/net/ipv4/netfilter/ipt_REJECT.c	Thu Sep 18 23:00:58 2003
@@ -34,16 +34,17 @@
 		attach(new_skb, nfct);
 }
 
-static inline struct rtable *route_reverse(struct sk_buff *skb, int local)
+static inline struct rtable *route_reverse(struct sk_buff *skb, int hook)
 {
 	struct iphdr *iph = skb->nh.iph;
 	struct dst_entry *odst;
 	struct rt_key key = {};
 	struct rtable *rt;
 
-	if (local) {
+	if (hook != NF_IP_FORWARD) {
 		key.dst = iph->saddr;
-		key.src = iph->daddr;
+		if (hook == NF_IP_LOCAL_IN)
+			key.src = iph->daddr;
 		key.tos = RT_TOS(iph->tos);
 
 		if (ip_route_output_key(&rt, &key) != 0)
@@ -75,7 +76,7 @@
 }
 
 /* Send RST reply */
-static void send_reset(struct sk_buff *oldskb, int local)
+static void send_reset(struct sk_buff *oldskb, int hook)
 {
 	struct sk_buff *nskb;
 	struct tcphdr *otcph, *tcph;
@@ -104,7 +105,7 @@
 			 csum_partial((char *)otcph, otcplen, 0)) != 0)
 		return;
 
-	if ((rt = route_reverse(oldskb, local)) == NULL)
+	if ((rt = route_reverse(oldskb, hook)) == NULL)
 		return;
 
 	hh_len = (rt->u.dst.dev->hard_header_len + 15)&~15;
@@ -372,7 +373,7 @@
 		send_unreach(*pskb, ICMP_PKT_FILTERED);
 		break;
 	case IPT_TCP_RESET:
-		send_reset(*pskb, hooknum == NF_IP_LOCAL_IN);
+		send_reset(*pskb, hooknum);
 	case IPT_ICMP_ECHOREPLY:
 		/* Doesn't happen. */
 		break;

[-- Attachment #3: y.diff --]
[-- Type: text/plain, Size: 501 bytes --]

===== net/ipv4/netfilter/ipt_REJECT.c 1.13 vs edited =====
--- 1.13/net/ipv4/netfilter/ipt_REJECT.c	Fri Jul 25 23:15:41 2003
+++ edited/net/ipv4/netfilter/ipt_REJECT.c	Thu Sep 18 23:28:49 2003
@@ -186,10 +186,6 @@
 	nskb->nh.iph->check = ip_fast_csum((unsigned char *)nskb->nh.iph, 
 					   nskb->nh.iph->ihl);
 
-	/* "Never happens" */
-	if (nskb->len > nskb->dst->pmtu)
-		goto free_nskb;
-
 	connection_attach(nskb, oldskb->nfct);
 
 	NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, nskb, NULL, nskb->dst->dev,

Re: Netfilter problem with new 2.4.22

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]

On Thu, Sep 18, 2003 at 11:40:02PM +0200, Patrick McHardy wrote:
> Hi Diadon,
> the problem seems to be that a dst for local input doesn't carry pmtu 
> information, the pmtu is set by rt_set_nexthop which is skipped for
> local input. 

Thanks for debugging the problem, Patrick.
 
> I've attached two possible fixes for this. The first one restores
> behaviour from before the routing changes for LOCAL_OUT, the other one
> removes the check since obviously "Never happens" is not true anymore
> (and it is not an error). Another possibility would be something like
> "if (nskb->dst->pmtu && nskb->len > nskb->dst->pmtu)  ..."
> Someone from the coreteam should comment which solution is prefered.

I'd actually prefer the last solution (together with a comment why
nskb->dst-pmtu can be zero). 

I've included the patch into 'submitted' (will send it to davem later)

> Regards,
> Patrick

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Netfilter problem with new 2.4.22

[Diadon]

That patch is not work, after patching the kernel problem is not 
disappeared!

Re: Netfilter problem with new 2.4.22

[Diadon]

That patch is not work, after patching the kernel problem is not
disappeared!

Netfilter problem with new 2.4.22

[Diadon]

After installing 2.4.22
this chain doesn't work
$IPPROG -A OUTPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

On 2.4.21 all works fine
In tcpdump on 2.4.21:
14:41:41.752557 somehost.auth > somehost1.32825: R 0:0(0) ack 217583467
win 0 (DF)

In tcpdump on 2.4.22:
nothing.......


any ideas?

Netfilter problem with new 2.4.22

[Diadon]

After installing 2.4.22
this chain doesn't work
$IPPROG -A OUTPUT -p tcp --dport 113 -j REJECT --reject-with tcp-reset

On 2.4.21 all works fine
In tcpdump on 2.4.21:
14:41:41.752557 somehost.auth > somehost1.32825: R 0:0(0) ack 217583467 
win 0 (DF)

In tcpdump on 2.4.22:
nothing.......


any ideas?

Re: Netfilter problem with new 2.4.22

[Harald Welte]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]

On Tue, Sep 16, 2003 at 02:22:37PM +0400, Diadon wrote:
> After installing 2.4.22
> this chain doesn't work

please post iptables related questions to netfilter@lists.netfilter.org
or netfilter-devel@lists.netfilter.org.  I'm forwarding your mail there.

> any ideas?

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]