Re: [Cerowrt-devel] Field Report on CeroWrt 3.10.24-1

[Sebastian Moeller <moeller0@gmx.de>]

Hi Dave, hi list

On Dec 15, 2013, at 19:16 , Dave Taht <dave.taht@gmail.com> wrote:

> On Sat, Dec 14, 2013 at 9:16 PM, Rich Brown <richb.hanover@gmail.com> wrote:
>> I did a tftp install of CeroWrt 3.10.42-1 on my secondary WNDR3800. I then used the “secondary” 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:
>> 
>> 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)
>> 
>> 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.
> 
> 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)
> 
> I don't know how to represent this properly in the gui.
> 
>> 2) None of the wireless SSIDs (2.4 or 5 GHz) allowed connections. It appears that they’re there, my MacBook sees them, but it cannot get an address for itself on those SSIDs.
>> 
>> 3) Clicking the AQM tab gave the following diagnostic info:
>> 
>> /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 </usr/lib/lua/luci/dispatcher.lua:194>
> 
> Fixed in git head
> 
>> 3a) To work around this (as noted in another message on the list), remove leading “s” of line 63 of /usr/lib/lua/luci/model/cbi/aqm.lua to read:
>> 
>> c:depends("advanced", "1”)
>> 
>> 4) In the AQM tab, I’m 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 “do the right thing” for the majority of people, so we don’t have to explain it very often.)
> 
> 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. 
	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. 
	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…
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


> 
>> 5) I did *not* try the Hurricane Electric 6in4 tunnel.
> 
> as a secondary router it would be better to assign it addresses on
> your existing /48
>> Best regards,
>> 
>> Rich Brown
>> Hanover, NH
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
> 
> 
> -- 
> Dave Täht
> 
> 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