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 1491321F1D4 for ; Sun, 15 Dec 2013 04:09:08 -0800 (PST) Received: from u-089-cab204a2.am1.uni-tuebingen.de ([134.2.89.3]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Lw285-1VSXNM1eUX-017omX for ; Sun, 15 Dec 2013 13:09:05 +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: <52AD98B1.80705@imap.cc> Date: Sun, 15 Dec 2013 13:09:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <046607BE-7AA5-441C-BBD7-3B5F01651B0A@gmx.de> References: <472E1EFA-1D6E-460B-AB2E-6E55D63184AD@gmail.com> <62C46991-29BF-40D7-8D4F-D3B2E27A87D7@gmx.de> <52AD98B1.80705@imap.cc> To: Fred Stratton X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:FWLs3iKJ8p6VXfiYpPE3Trhuf5LAXXegZhEyWOg9A553mhvh7/y oOQFoOtXe3ZuwyzBbZV2PEZ2WoxXixLbvdItcfUoZgyPACF1mqncLMZj897zwXDmvugQuZ3 Y6o8K/r65wbh+Jy1HsXNG+muEVmrOY7egt7uZqdy0JQtC46zDK7YRHLSm56vsXIjKnGaMkC bA6ZZCkVTx80YLgllVzDA== 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 12:09:08 -0000 Hi Fred, thanks to your input. On Dec 15, 2013, at 12:55 , Fred Stratton wrote: > Over the last 30 years, graphical interfaces have been bloated with = pages of explanatory text. >=20 > If more explanation of the interface is required, it could be = incorporated in the wiki. Links could also be incorporated in the wiki. So, I think it would be nice if the GUI contains enough = information for a typical user to set up the system and forget about it. = Alas, the ATM encapsulation is a bit complicated and arcane, so a bit of = explanation seems required. What does the rest of you think: keep the = GUI clean or include a bit background information?=20 >=20 > I suggest the AQM lua interface is kept simple and therefore easier to = maintain. I hope that there is not much maintenance necessary once all = features are supported. At least I the ATM encapsulation issues, = hopefully, are constant and will not change in the future=85 (except, I = dream, they will become obsolete once ATM goes the way of the Dodo=85). But, hey, so far we have one voice for more detail/instructions = and one for terseness.=20 As said before, I will still try to rearrange the AQM single tab = into a collection of tabs, that should allow to include a bit more help, = hopefully without sacrificing simplicity too much; so in the end both = Rich and Fred might find it acceptable. (It just means that we will have = to choose the terse help text very carefully; help would be greatly = appreciated) Best Sebastian >=20 >=20 > On 15/12/13 11:33, Sebastian Moeller wrote: >> Hi Rich, >>=20 >>=20 >> On Dec 15, 2013, at 06:16 , Rich Brown = wrote: >>=20 >>> 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 >>> 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 >>> 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...) >>=20 >>=20 >>> 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...) >>=20 >>> (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 >>=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 >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20