"ip_conntrack_core: Frag of proto 17." error

"ip_conntrack_core: Frag of proto 17." error

[c0g]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi
I'm getting lots of these errors. I read in ip_conntrack_core.c it
should "never happen" (so it's kind of assertion). Why does this
assertion fail?

I'm using 2.4.22 kernel with CVS p-o-m 20030907. I'm using only
following major netfilter patches:

TCPLAG.patch
ipt_REJECT-fake-source.patch
raw.patch

and some minor:

39_ip_conntrack-proc.patch
40_nf-log.patch
54_ip_nat-macro-args.patch
58-ip_conntrack-macro-args.patch
59_ip_nat_h-unused-var.patch
60_nat_tftp-remove-warning.patch
61-remove-memsets.patch
63_getorigdst-tuple-zero.patch
74_nat-range-fix.patch
ip_ct_refresh_optimization.patch

- --
c0g@wp.pl

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/ac/2PqmVt5WhbA8RAm7oAJ9W+KUw6f4su9mpKUjMCbieracD+wCdHfut
3A++Y9/gobZCg/EwTCAlZhQ=
=zvIJ
-----END PGP SIGNATURE-----

Re: "ip_conntrack_core: Frag of proto 17." error

[Harald Welte]

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

On Thu, Sep 18, 2003 at 05:32:06PM +0200, c0g wrote:
 
> Hi
> I'm getting lots of these errors. I read in ip_conntrack_core.c it
> should "never happen" (so it's kind of assertion). Why does this
> assertion fail?

Indeed.  It seems like you have fragmens inside connection tracking.
However, all packets are defragmented before connection tracking
happens.

Can you please tell us more about your setup?  Something special with
regard to networking?  Tunnels? IPSec?

Maybe you can add a printk to print out the address information (or use
DUMP_TUPLE on the tuple) of the packet... maybe this way you can
identify where it came from (through which interface[s], processing,
...).


> c0g@wp.pl

-- 
- 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: "ip_conntrack_core: Frag of proto 17." error

[c0g]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

|>I'm getting lots of these errors. I read in ip_conntrack_core.c it
|>should "never happen" (so it's kind of assertion). Why does this
|>assertion fail?
|
|
| Indeed.  It seems like you have fragmens inside connection tracking.
| However, all packets are defragmented before connection tracking
| happens.
|
| Can you please tell us more about your setup?  Something special with
| regard to networking?  Tunnels? IPSec?
|
| Maybe you can add a printk to print out the address information (or use
| DUMP_TUPLE on the tuple) of the packet... maybe this way you can
| identify where it came from (through which interface[s], processing,
| ...).

Hi. My setup is simple. This is box with 5 nics, which is primary a PPTP
server for authorizing LAN users:
eth0 - 192.168.0.200/18 - users lan (big)
eth1 - 192.168.64.200/24 - users lan2 (small)
eth2 - 192.168.80.200/24 - dmz
eth3 - 192.168.72.200/24 - default route
eth4 - 192.168.112.200/24 - net containing loghost (tcpdump showed most
of fragments was syslog messages)

Transparent proxying, qos, nat is being done on next hops on default
route - outside this box.

For now, PPTP is used only on eth1 - there was no fragments from this
net (except some tests with icmp I have done). So PPTP is not important.

I attached tcpdump to every interface with a rule to catch fragments:
tcpdump -c 1000 -s 65000 -w ethx-frags.dump -pni eth1 ip[6:2] & 0x1fff != 0

Then I parsed kern.log* to find out when "frag of proto" warning and
subsequent "last message repeated x times" was appearing.

And then I compared times when:
- - fragments was captured by tcpdump
- - "Frag of proto" message was logged

It seems kernel barks only on fragments destined to Internet from lan at
eth0. It ignores fragments generated by syslog messages, because they
source and destination address is local.
So it confirms that problem is in raw table, because in my setup raw
table catches only local<->remote packets.

How to simply repeat the bug:
Host A and host B are separated by router.
On router: insert netfilter rule in raw table which does NOTRACK on
packets from A to B.
# iptables -t raw -I PREROUTING -s HOST_A -d HOST_B -j NOTRACK
On host A: send fragments to B.
# ping -s 2000 HOST_B

Result: Router logs "Frag of proto" message.

- --
c0g@wp.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/br/EPqmVt5WhbA8RAqLxAKCADuQ/A17uNSCjsk2oImoEJj/KfQCgjF4K
2kVIHqMDlT/LWaMtW6XqkgU=
=Ocpj
-----END PGP SIGNATURE-----

Re: "ip_conntrack_core: Frag of proto 17." error

[c0g]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| I attached tcpdump to every interface with a rule to catch fragments:
| tcpdump -c 1000 -s 65000 -w ethx-frags.dump -pni eth1 ip[6:2] & 0x1fff
!= 0
|
| Then I parsed kern.log* to find out when "frag of proto" warning and
| subsequent "last message repeated x times" was appearing.

And dump files are available here:
http://c0g.webpark.pl/frags/frags.tar.gz

- --
c0g@wp.pl
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/bsRHPqmVt5WhbA8RAvNuAJ4n+ytclgMMlNeaHy6+xITiBD/nxQCfakKA
Q0uuBA5eifPfA3t3pUUNhlU=
=xDWF
-----END PGP SIGNATURE-----

Re: "ip_conntrack_core: Frag of proto 17." error

[Harald Welte]

[-- Attachment #1.1: Type: text/plain, Size: 925 bytes --]

On Mon, Sep 22, 2003 at 11:26:15AM +0200, c0g wrote:
 
> Hi. My setup is simple. This is box with 5 nics, which is primary a PPTP
> server for authorizing LAN users:

thanks.  As already discovered by Martin Josefsson, the problem is the
NOTRACK target.  We have to fix NOTRACK in order to get rid of this bug.

We are waiting for Jozsef (the author of NOTRACK) to comment on this.

Meanwhile, try using the attached (experimental, untested) patch on top
of your (already patched) kernel. Please report back to us if it works.

thanks.


-- 
- 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 #1.2: notrack-nodefrag-fix.patch --]
[-- Type: text/plain, Size: 694 bytes --]

--- linux-notrack/net/ipv4/netfilter/ipt_NOTRACK.c	2003-09-22 12:09:59.000000000 +0200
+++ linux-notrack-nodefrag/net/ipv4/netfilter/ipt_NOTRACK.c	2003-09-22 12:10:44.000000000 +0200
@@ -23,14 +23,8 @@
 	if ((*pskb)->nfct != NULL)
 		return IPT_CONTINUE;
 
-	proto = ip_ct_find_proto((*pskb)->nh.iph->protocol);
-
-	if (ip_conntrack_get_tuple((*pskb)->nh.iph, (*pskb)->len, 
-		      &tuple, proto)
-	    && !ip_conntrack_tuple_taken(&tuple, NULL)) {
-		(*pskb)->nfct = &ip_conntrack_untracked.infos[IP_CT_NEW];
-		nf_conntrack_get((*pskb)->nfct);
-	}
+	(*pskb)->nfct = &ip_conntrack_untracked.infos[IP_CT_NEW];
+	nf_conntrack_get((*pskb)->nfct);
 
 	return IPT_CONTINUE;
 }

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