From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 0514621F0B3 for ; Mon, 4 Feb 2013 08:46:24 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id k10so5872707iea.5 for ; Mon, 04 Feb 2013 08:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=V+WOdtqRQKtziQiSUoQf6R/ZYORIUAR7u7XkdKMIGwo=; b=W5Dy52TA10vZoB0wdoTs9dArN8N3plkL0JzCWRk+fL/OOr5Geqp0tYSmISl8lVD3Ty 5VvSRIY02aKb6wqn2Y9MT8ju93QhAdh9EfASyM0Xp0Ux+36qSbirSJNHS01wrtf2GhfX z+eZxFXL/mcCRmEQg1S82wbELtl/Z4HE399VkRPr+cJ/wqmJn6vyaY47T1cZ6I6uV6Yy KXgPeqiQP9/p+RBpc8SDs6VeaTQhw3h5xjEj4nf3XMNIAiHIzYSdrdcb79uSrGXdJx4Q 0+V6P1BOuULBkvWUFiUHYvavX81hVepjekd+fQNbZ4fPZDWNmVRcP0FNaBFx7OPop1hG WbSA== MIME-Version: 1.0 X-Received: by 10.50.100.170 with SMTP id ez10mr3554716igb.27.1359996384345; Mon, 04 Feb 2013 08:46:24 -0800 (PST) Received: by 10.64.135.39 with HTTP; Mon, 4 Feb 2013 08:46:24 -0800 (PST) Date: Mon, 4 Feb 2013 08:46:24 -0800 Message-ID: From: Dave Taht To: cerowrt-devel@lists.bufferbloat.net Content-Type: multipart/alternative; boundary=e89a8f3b9e5f62803104d4e8d59c Subject: [Cerowrt-devel] dealing with nat and the crc issue I'd had X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 16:46:25 -0000 --e89a8f3b9e5f62803104d4e8d59c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It turns out to save on cpu and deal with some broken clients, conttrack doesn't checksum by default. I just turned it back on. echo 1 > /proc/sys/net/netfilter/nf_conntrack_checksum echo 1 > /proc/sys/net/ipv4/netfilter/ip_conntrack_checksum I think leaving it on is a good idea and will probably do so in a follow on release, but am open to opinions. AND: I think this is a bug in cero on larger networks. I have seen in the field timeouts (far) lower than 3600, and I think the rfc is 7200, and I have no idea why I put this in there... except that I used to (before I switched to mosh= ) maintain a lot of long running ssh sessions. net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=3D432000 One behavior I've been battling, has been "after a while", a given radio would be able to forward packets around the internal network just fine. But: frequently you can get stuff through the gateway, but after a couple hops things would fail to return, so I first suspected crc (which I'm mostly putting down to the tcpdump tool not the network right now), then nat. So I can see the above value exausting the nat table... going to get rid of the double-nat today or tomorrow --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --e89a8f3b9e5f62803104d4e8d59c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It turns out to save on cpu and deal with some broken clients,
conttrack= doesn't checksum by default. I just turned it back on.

echo 1 &= gt; /proc/sys/net/netfilter/nf_conntrack_checksum
echo 1 > /proc/sys/= net/ipv4/netfilter/ip_conntrack_checksum

I think leaving it on is a good idea and will probably do so in
a fo= llow on release, but am open to opinions.

AND:

I think this i= s a bug in cero on larger networks. I have seen in the field
timeouts (f= ar) lower than 3600, and I think the rfc is 7200, and I have no idea
why I put this in there... except that I used to (before I switched to mosh= )
maintain a lot of long running ssh sessions.

net.ipv4.netfilter= .ip_conntrack_tcp_timeout_established=3D432000

One behavior I've= been battling, has been "after a while", a given radio
would be able to forward packets around the internal network just fine.
=
But: frequently you can get stuff through the gateway, but after a coup= le hops
things would fail to return, so I first suspected crc (which I&#= 39;m mostly putting
down to the tcpdump tool not the network right now), then nat. So I can
= see the above value exausting the nat table...

going to get rid of t= he double-nat today or tomorrow



--
Dave T= =E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subs= cribe.html=20 --e89a8f3b9e5f62803104d4e8d59c--