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 4B919200203 for ; Sun, 15 Dec 2013 11:25:08 -0800 (PST) Received: from hms-beagle-3.home.lan ([87.150.22.181]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LgZdt-1VE3DI2vvJ-00nxJp for ; Sun, 15 Dec 2013 20:25: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: Date: Sun, 15 Dec 2013 20:25:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <472E1EFA-1D6E-460B-AB2E-6E55D63184AD@gmail.com> To: Dave Taht X-Mailer: Apple Mail (2.1510) X-Provags-ID: V03:K0:JEM11hFM1WYETm86WTV5y/OgV9jyg4Uez4KsANhL7flidwZp61b FvKHbzdXGV9/A/0M8jxxhmN8iNc2mPqfQlpsCU3JrItDLS/PGpjjDN0C0ggVyPOjln1aHVA VKD8Gcnp9AJhe+GnM5cb940nkb/Qt091XXO4R5xUi5Ab55D5B0DLtSviMBfS6RxG8fjHHPt WZ9r3MBLVFJQ7afr0BWdQ== 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 19:25:08 -0000 Hi Dave, hi list On Dec 15, 2013, at 19:16 , Dave Taht wrote: > On Sat, Dec 14, 2013 at 9:16 PM, 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 >> 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 > We are using the + syntax to put stuff in their proper zones. It's > faster, but doesn't show up in the guy properly. > E.g. s+ is the secure zone (1 firewall rule instead of 3) and gw+ is > the guest zone (1 firewall rule instead of 4) >=20 > I don't know how to represent this properly in the gui. >=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 > Fixed in git head >=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) >>=20 >> 4) In the AQM tab, I=92m not sure which linklayer adaptation = mechanism to use. It would be good to have a concise summary of the = proper settings for various use cases. (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.) >=20 > I agree that that page is puzzling as hell, and needs a pointer to > what sorts of DSL services require it. Hmm, so I will have a go at hiding the non-essential fields = unless the user requests "advanced detail" or some such.=20 Typically the link layer type and the overhead will need to be = configurable; tcMTU, tsize, and MPU could be hidden away I guess. Also I = can hide the htb_private method some more.=20 All ATM based transports require either "adel" or "atm" as link = layer to account for (both are aliases in the kernel and we could = simplify, by just exposing one in the GUI). Now as far as I know the = following use ATM at least on the last mile and are therefore = "eligible": ADSL1, ADSL2, ADSL2+. Now it gets complicated, VDSL(1) theoretically also might run = over ATM, even though they typically use PTM (which needs no special = link layer, or better would like a link layer HDCL, but I digress); = VDSL2, to my knowledge, does not support ATM as link layer. I would = assume that al sane carriers not cornered in will use PTM for all VDSLs = though. All xDSLs will require a proper overhead specified, again, = overheads on ATM based systems are in general larger and hence more = important to get right=85 In the end the only good way to keep the GUI simple, would be to try to = auto detect the link layer, but I have found no fast way of doing so. = Maybe someone in the audience has a good idea? Best sebastian >=20 >> 5) I did *not* try the Hurricane Electric 6in4 tunnel. >=20 > as a secondary router it would be better to assign it addresses on > your existing /48 >> Best regards, >>=20 >> Rich Brown >> Hanover, NH >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >=20 >=20 >=20 > --=20 > Dave T=E4ht >=20 > Fixing bufferbloat with cerowrt: = http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel