From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3712C21F1AA for ; Mon, 17 Mar 2014 07:55:29 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id x48so4711454wes.10 for ; Mon, 17 Mar 2014 07:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=INSHqD+Y7DwQP8LTn4EmV5ZznkTXIIwf3pluanAkc9Q=; b=UxHYDHhmrd4tJvuaDScGwvLLBuo0WFqcMmFBq6sNOoAB2q2pz+nWIF8bXRss78F5wk Q2zGGDs6Bsz5D7/8UIeIDL5MJqRXaUE45gsVbitLr4YglSIkqXysD5bzxAYIbjiTF+PE HDlFkY1o1KT1HFw3S5z+3PeNF9uaziflBfbe6eOjL1Zx1pMxwJOZuCL90fiWuHFQJFot udKUEhzWdZLX6CsAsHIHJnZUk3F0xg+U57jJzQ0mad7s11Yb21aDYSGQYNrBt6a5EscV Ts8KTTsqHRmUMnGqSWa4i9cB8ej6eNaSfuBSB/eQmwqmUFyCHct61Z1kxzNcXy8q9Pqr KOuQ== MIME-Version: 1.0 X-Received: by 10.195.13.103 with SMTP id ex7mr18722663wjd.3.1395068127250; Mon, 17 Mar 2014 07:55:27 -0700 (PDT) Received: by 10.216.8.1 with HTTP; Mon, 17 Mar 2014 07:55:27 -0700 (PDT) In-Reply-To: <87eh20lwx5.fsf@toke.dk> References: <5162.1395058842@sandelman.ca> <87eh20lwx5.fsf@toke.dk> Date: Mon, 17 Mar 2014 07:55:27 -0700 Message-ID: From: Dave Taht To: =?ISO-8859-1?Q?Toke_H=F8iland=2DJ=F8rgensen?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] cerowrt-3.10.32-9 released 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, 17 Mar 2014 14:55:29 -0000 On Mon, Mar 17, 2014 at 7:30 AM, Toke H=F8iland-J=F8rgensen = wrote: > Dave Taht writes: > >> At least one blueray player we know of isn't working through the >> default dhcp/dns/upnp setup. > > Why would a bluray player need upnp? *shudder* It's a sony. Where products from that org are concerned, I tend to suspect they will be reporting back to the mothership. >> I've modeled something that basically should work in my bcp38 repo. > > So, not sure exactly how it's supposed to work; does this hook into the > firewall after NAT'ing has been applied? Otherwise you'd presumably need > to add exceptions for the configured internal network(s)? (I think that > may be what is going on in the bcp script at ln 38, but some sort of > auto-detection of the relevant network(s) would be needed? Or as a > minimum a whitelist configuration option?) It would hook into the wan firewall rules regardless of NAT. So there is no need to specifically exempt internal addresses. The situation we want to prevent is packets sourced from a NATted address exiting the wan say your network is 172.30.42.0/24. Someone starts pinging 172.29.42.1 from inside your network. The default non-source-specific route will then send those packets out the wan, with a source address of your default gw and a destination of 172.29.42.1... where they will wander the internet until someone drops them, which can be quite far out. In the case of the dsl box I'm testing today, they do get dropped at the first hop. On cable I've seen 3-5 hops. I didn't claim it all worked yet. The core remaining problem is detecting a double nat situation via some dhcp hook and adding an exception for that network and it's default netmask and default gateway. > > Could double-nat be detected from wan iface hotplug or somesuch? I would hope so. But haven't found the hook yet. (and the resulting table needs to be preserved across dhcp renews and other network activity, which is in part why it's not setup in the firewall rules in the testy scripts...) >> That said, surviving an ipv6 renumber is a problem. Many clients >> probably don't respect an address assignment lifetime. > > Application-transparent MPTCP from the operating system with automatic > failover? Pretty please? :) Linux kernel patches for that are available. They are quite invasive and I don't know when they will make mainline linux. http://multipath-tcp.org/pmwiki.php?n=3DMain.Release88 I'd like to see netperf support added to that. > > -Toke --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html