Bug#410857: NFS breaks down because of errors in connection tracking
On Tue, Feb 13, 2007 at 11:14:17PM +0100, Georg Mainik wrote: Package: linux-image-2.6.18-3-686 Version: 2.6.18-7 Severity: normal Hello, this is my first bug report and I am trying my best to submit it in a correct way and to give enough information for solving the problem. After installing and configuring a firewall, (Shorewall) I observed that NFS broke down on the clients after a reboot -- not always, but in 80% of all cases. With some help from a friend, I could find out that there was an inconsistency in connection tracking: although the NFS connection was established by the client, the NFS packages sent by the server did not pass the sequence number check. After adding a log target to Shorewall's dropInvalid chain (there is none by default), I saw the following in the syslog: - [..] - With some more help, I got a workaround for that: echo 1 /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal After including this line into Shorewall's post-init script, the NFS connection did not break down any more. I don't know whether the origin of the problem is in the netfilter or in the nfs server or in the connection tracking on the client or server (maybe the server does not notice the client reboot and goes on with sequence numbers from the old connections?), but it is in the kernel -- the firewall rules are correct and the packages are not recognized as a part of the existing connection. Does this error still occur with more recent kernel versions? Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#410857: NFS breaks down because of errors in connection tracking
Package: linux-image-2.6.18-3-686 Version: 2.6.18-7 Severity: normal Hello, this is my first bug report and I am trying my best to submit it in a correct way and to give enough information for solving the problem. After installing and configuring a firewall, (Shorewall) I observed that NFS broke down on the clients after a reboot -- not always, but in 80% of all cases. With some help from a friend, I could find out that there was an inconsistency in connection tracking: although the NFS connection was established by the client, the NFS packages sent by the server did not pass the sequence number check. After adding a log target to Shorewall's dropInvalid chain (there is none by default), I saw the following in the syslog: - Feb 8 17:03:14 client-name kernel: ip_ct_tcp: SEQ is over the upper bound (over the window of the receiver) IN= OUT= SRC=server-IP-addr DST=client-IP-addr LEN=1084 TOS=0x00 PREC=0x00 TTL=64 ID=1679 DF PROTO=TCP SPT=2049 DPT=702 SEQ=1700263068 ACK=605923012 WINDOW=448 RES=0x00 ACK PSH URGP=0 OPT (0101080A03BA7D57A04A) Feb 8 17:03:14 client-name kernel: ip_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT= SRC=client-IP-addr DST=server-IP-addr LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=25485 DF PROTO=TCP SPT=702 DPT=2049 SEQ=605923012 ACK=1700264100 WINDOW=284 RES=0x00 ACK URGP=0 OPT (0101080AA04A03BA7D57) Feb 8 17:03:14 client-name kernel: ip_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT= SRC=client-IP-addr DST=server-IP-addr LEN=200 TOS=0x00 PREC=0x00 TTL=64 ID=25486 DF PROTO=TCP SPT=702 DPT=2049 SEQ=605923012 ACK=1700264100 WINDOW=284 RES=0x00 ACK PSH URGP=0 OPT (0101080AA04B03BA7D57) Feb 8 17:03:14 client-name kernel: ip_ct_tcp: SEQ is over the upper bound (over the window of the receiver) IN= OUT= SRC=server-IP-addr DST=client-IP-addr LEN=172 TOS=0x00 PREC=0x00 TTL=64 ID=1680 DF PROTO=TCP SPT=2049 DPT=702 SEQ=1700264100 ACK=605923160 WINDOW=456 RES=0x00 ACK PSH URGP=0 OPT (0101080A03BA7D58A04B) Feb 8 17:03:14 client-name kernel: ip_ct_tcp: ACK is over the upper bound (ACKed data not seen yet) IN= OUT= SRC=client-IP-addr DST=server-IP-addr LEN=192 TOS=0x00 PREC=0x00 TTL=64 ID=25487 DF PROTO=TCP SPT=702 DPT=2049 SEQ=605923160 ACK=1700264220 WINDOW=284 RES=0x00 ACK PSH URGP=0 OPT (0101080AA04F03BA7D58) - With some more help, I got a workaround for that: echo 1 /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_be_liberal After including this line into Shorewall's post-init script, the NFS connection did not break down any more. I don't know whether the origin of the problem is in the netfilter or in the nfs server or in the connection tracking on the client or server (maybe the server does not notice the client reboot and goes on with sequence numbers from the old connections?), but it is in the kernel -- the firewall rules are correct and the packages are not recognized as a part of the existing connection. Thanks, Georg Here the system information about the client: -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages linux-image-2.6.18-3-686 depends on: ii coreutils 5.97-5 The GNU core utilities ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii initramfs-tools [linux-initra 0.85e tools for generating an initramfs ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.18-3-686 recommends: ii libc6-i686 2.3.6.ds1-10 GNU C Library: Shared libraries [i -- debconf information: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-3-686/postinst/bootloader-error-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/old-dir-initrd-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/kimage-is-a-directory: linux-image-2.6.18-3-686/preinst/elilo-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/old-system-map-link-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/lilo-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/depmod-error-initrd-2.6.18-3-686: false linux-image-2.6.18-3-686/preinst/bootloader-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/prerm/removing-running-kernel-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/create-kimage-link-2.6.18-3-686: true linux-image-2.6.18-3-686/prerm/would-invalidate-boot-loader-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/abort-install-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/overwriting-modules-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/initrd-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/lilo-has-ramdisk:
