A typical user of ceroWRT probably:

 has worked in a university, or held a university post;
probably speaks more than one language, including English and American English;
is proficient at using a command line interface, together with vim or emacs;
has a working knowledge of Perl syntax;

as a bare minimum, apart from knowledge of internet hardware and software constructs.

Such as user, I argue, is capable of reading a wiki.

On 15/12/13 12:09, Sebastian Moeller wrote:
Hi Fred,

thanks to your input.


On Dec 15, 2013, at 12:55 , Fred Stratton <fredstrat...@imap.cc> wrote:

Over the last 30 years, graphical interfaces have been bloated with pages of 
explanatory text.

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?

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… (except, I dream, they will become 
obsolete once ATM goes the way of the Dodo…).
        But, hey, so far we have one voice for more detail/instructions and one 
for terseness.
        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


On 15/12/13 11:33, Sebastian Moeller wrote:
Hi Rich,


On Dec 15, 2013, at 06:16 , Rich Brown <richb.hano...@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.

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>

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”)
        Sorry for that, I committed an untested change (adding two lines, how 
much can go wrong?) and forgot to edit the 2nd copy...

4) In the AQM tab, I’m 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 “do the right thing” for the 
majority of people, so we don’t 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…
        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...


5) I did *not* try the Hurricane Electric 6in4 tunnel.

Best regards,

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

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to