From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BC37621F1DA for ; Sun, 15 Dec 2013 03:33:44 -0800 (PST) Received: from u-089-cab204a2.am1.uni-tuebingen.de ([134.2.89.3]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0LnkiR-1VKBuU3DEV-00hvKm for ; Sun, 15 Dec 2013 12:33:41 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sebastian Moeller In-Reply-To: <472E1EFA-1D6E-460B-AB2E-6E55D63184AD@gmail.com> Date: Sun, 15 Dec 2013 12:33:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <62C46991-29BF-40D7-8D4F-D3B2E27A87D7@gmx.de> References: <472E1EFA-1D6E-460B-AB2E-6E55D63184AD@gmail.com> To: Rich Brown X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:pAGvoVTe1vmQUUqMpB4bQk5EWMy4+FOkuJ7d2pOA0Rm841DhKf1 m1o2HUyCepiO1S+ugl3pEnj9hJEtoyOhcllTfL0XQvlKgwDSFPdL1FmOmk7oP3ns33HaJOW Izs1W6cIlGI05SyLmMek719B1OKC7e2S3dnoXU2MTu87amNopj5ZPd/dDxnKPoCOSHPGhhC FoggXKZjj3g00+9D2fcsw== Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Field Report on CeroWrt 3.10.24-1 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: Sun, 15 Dec 2013 11:33:45 -0000 Hi Rich, On Dec 15, 2013, at 06:16 , Rich Brown wrote: > I did a tftp install of CeroWrt 3.10.42-1 on my secondary WNDR3800. I = then used the =93secondary=94 script to reconfigure the subnets and = SSIDs to be different from my primary CeroWrt router. I know that a lot = of things are still in flux, but I thought I should comment that I = noticed the following: >=20 > 0) It seems to work mostly. I could connect my MacBook on Ethernet, = but not wireless (see below) I ran RRUL with reasonable results (I = think)=20 >=20 > 1) Only the ge00 interface was in its proper firewall zone (wan); I = used the GUI to move all the gwxx to guest and se00 and swxx interfaces = to lan. >=20 > 2) None of the wireless SSIDs (2.4 or 5 GHz) allowed connections. It = appears that they=92re there, my MacBook sees them, but it cannot get an = address for itself on those SSIDs. =20 >=20 > 3) Clicking the AQM tab gave the following diagnostic info: >=20 > /usr/lib/lua/luci/dispatcher.lua:448: Failed to execute cbi dispatcher = target for entry '/admin/network/aqm'. > The called action terminated with an exception: > /usr/lib/lua/luci/model/cbi/aqm.lua:63: attempt to index global 'sc' = (a nil value) > stack traceback: > [C]: in function 'assert' > /usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch' > /usr/lib/lua/luci/dispatcher.lua:195: in function = >=20 > 3a) To work around this (as noted in another message on the list), = remove leading =93s=94 of line 63 of /usr/lib/lua/luci/model/cbi/aqm.lua = to read: >=20 > c:depends("advanced", "1=94) Sorry for that, I committed an untested change (adding two = lines, how much can go wrong?) and forgot to edit the 2nd copy... >=20 > 4) In the AQM tab, I=92m not sure which linklayer adaptation mechanism = to use. If you have DSL either is good. In case you work with jumbo = packets on ge00 or use GSO you should use htb_private, otherwise both = are fine. (I will try to get patches for tc_stab into the kernel that = makes this difference moot ad might alls us to consolidate on the = generic tc_stab). I will add this information onto the GUI. (Since there = are only few users for the link layer adjustments, both methods are = somewhat prone to bitrott, so I think it has value to expose both so = that we can cross test both, assuming both will not go bad at the same = kernel revision...) > It would be good to have a concise summary of the proper settings for = various use cases. Well, yes it would, unfortunately it is slightly tricky to do = so. Dave proposed a redesign of the AQM GUI page with tabs for the = different functional pieces. When I prototype this I will try to include = more information about properly selecting those values. That said = typically mpu shopule be zero, tcMTU should be 2047 (as the interface = MTU will be around 1500), tsize should be 128. Overhead is the trickiest = as it depends on the actual encapsulation used on your link. If I am = correct the maximum for this is 44 and a typical value is 40, so we = could default to 44 to do no damage but we would waste bandwidth for = almost everybody. What do you think about including links in the GUI so = the user can go and read up on this? (I would recommend = http://www.faqs.org/rfcs/rfc2684.html and = http://ace-host.stuart.id.au/russell/files/tc/tc-atm/ but both are not = that easy to digest...) > (And to install a set of defaults that will =93do the right thing=94 = for the majority of people, so we don=92t have to explain it very = often.) Okay, realistically the most important thing is to select one of = the mechanisms to account for the link layer if you are on ATM based = DSL, so typically ADSL1, ADSL2, ADSL2+ (with an off chance with VDSL1), = assuming a typical link the link MTU will be ~1500 so the defaults for = tcMTU tsize and MPU will work fine. We could set the default link layer = to ADSL and the default overhead to 40 if Dave agrees, to preconfigure a = reasonable default=85 I have been thinking about how to detect the link layer = quantization and the protocol overhead automatically, but so far do not = have anything useful to include with cerowrt (on a fast link one needs = to measure all night to get small enough deviations to reliably detect = the quantisation). If you are willing to play guinea pig I will send you = the measurement script... >=20 > 5) I did *not* try the Hurricane Electric 6in4 tunnel. >=20 > Best regards, >=20 > Rich Brown > Hanover, NH > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel