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

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

[Rich Brown]

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”)

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.)

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

Best regards,

Rich Brown
Hanover, NH

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

[Sebastian Moeller]

Hi Rich,


On Dec 15, 2013, at 06:16 , 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.
> 
> 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

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

[Fred Stratton]

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.

I suggest the AQM lua interface is kept simple and therefore easier to 
maintain.


On 15/12/13 11:33, Sebastian Moeller wrote:
> Hi Rich,
>
>
> On Dec 15, 2013, at 06:16 , 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.
>>
>> 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

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

[Sebastian Moeller]

Hi Fred,

thanks to your input.


On Dec 15, 2013, at 12:55 , Fred Stratton <fredstratton@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.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.
>>> 
>>> 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
> 

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

[Fred Stratton]

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 <fredstratton@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.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.
>>>>
>>>> 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

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

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

Fred Stratton <fredstratton@imap.cc> writes:

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

Sure, put the long explanations in the wiki. But the whole point of
having a GUI (IMHO) is discoverability of options, and to contain enough
of a reference that it's not necessary to look at the documentation
every time, even for a seldomly used feature.

That being said, I agree that the GUI should not contain pages of
explanation. But a very terse explanation with a link to the wiki for
more information would work, I think. I.e. enough text to jog one's
memory after having read the wiki the first time around. :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

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

[Rich Brown]

Hi Sebastian, Fred, Toke,

Thanks for all these comments about the AQM GUI. It feels to me that we’re working on an interesting (GUI) design challenge along with all the technical wrassling that’s going on:

- Are we leaving enough knobs and levers exposed so that people can easily help us with research into the best settings?
- Are we aiming toward a set of default parameters that people can set and forget?

I suspect that the answer to both is “yes”, but the real question we’re talking about now is *when* we do each. My vote:

- For now, leave more knobs and levers exposed. If we do this...

- We need to provide guidance for these settings. I am not (yet) sufficiently familiar with the issues to make these judgements/decisions on my own. 

- I never want to see paragraphs of text in a GUI. That simply implies that the GUI needs to link to a page on the wiki with our collective wisdom on the subject. I’ll help with that.

Best,

Rich

On Dec 15, 2013, at 6:33 AM, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Rich,
> 
> 
> On Dec 15, 2013, at 06:16 , 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.
>> 
>> 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] CeroWrt 3.10.24-1/Wifi problems

[Rich Brown]

I played around a bit more with the wifi on CeroWrt 3.10.24-1, and discovered the ‘wifi' command gives a bunch errors. I don’t know if these are relevant. I’ve included the output of the wifi command, as well as the /etc/config/wireless file’s contents. 

The current state of wifi is:s

- The wifi channels are distinct between my primary router (1 & 36) and the secondary (6 & 44)
- In my secondary router, I used a “+” in the SSIDs to distinguish them from my primary router defaults.

- None of the SSIDs allow my computer to get an address
- My computer and wifi analyzer [1] show that CeroWrt is only transmitting some of the six SSIDs
- I ran the ‘wifi’ command three times and got different results each time. The attempts are detailed below.

I hope this is useful.

Rich

[1] I’m using farproc’s wonderful WifiAnalyzer on Android (https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer)

======= Try #1 - the following SSIDs work/don’t work =======
	CEROwrt+ (sw00) OK
	CEROwrt+guest (gw00) OK
	CEROwrt+guest5 (gw10) OK
	babel (2.4 & 5 GHz) (gw01 & gw11) OK
	CEROwrt5+ (sw10) No Signal

root@cerowrt:~# wifi
command failed: Too many open files in system (-23)
command failed: Device or resource busy (-16)
Configuration file: /var/run/hostapd-phy0.conf
nl80211: Could not configure driver mode
nl80211 driver initialization failed.
hostapd_free_hapd_data: Interface gw00 wasn't started
hostapd_free_hapd_data: Interface gw00 wasn't started
hostapd_free_hapd_data: Interface sw00 wasn't started
Failed to start hostapd for phy0
command failed: Too many open files in system (-23)
command failed: Too many open files in system (-23)
command failed: Device or resource busy (-16)
Configuration file: /var/run/hostapd-phy1.conf
nl80211: Could not configure driver mode
nl80211 driver initialization failed.
hostapd_free_hapd_data: Interface gw10 wasn't started
hostapd_free_hapd_data: Interface sw10 wasn't started
Failed to start hostapd for phy1
root@cerowrt:~#

====== Try # 2 ==============

CEROwrt+guest OK
CEROwrt+guest5 OK
babel (2.4 & 5GHz) drops out for 3-10 seconds every minute or so
CEROwrt5+ No Signal
CEROwrt+ No Signal

root@cerowrt:~# wifi
command failed: Device or resource busy (-16)
Configuration file: /var/run/hostapd-phy0.conf
nl80211: Could not configure driver mode
nl80211 driver initialization failed.
hostapd_free_hapd_data: Interface gw00 wasn't started
hostapd_free_hapd_data: Interface gw00 wasn't started
hostapd_free_hapd_data: Interface sw00 wasn't started
Failed to start hostapd for phy0
command failed: Too many open files in system (-23)
command failed: Too many open files in system (-23)
command failed: Device or resource busy (-16)
Configuration file: /var/run/hostapd-phy1.conf
nl80211: Could not configure driver mode
nl80211 driver initialization failed.
hostapd_free_hapd_data: Interface gw10 wasn't started
hostapd_free_hapd_data: Interface sw10 wasn't started
Failed to start hostapd for phy1
root@cerowrt:~#

====== Try #3 ==========

CEROwrt+ OK
CEROwrt+guest OK
CEROwrt+guest5 OK
babel 2.4GHz OK
babel 5GHz drops out for 3-10 seconds every minute or so
CEROwrt5+ Does Not Work (no signal)

root@cerowrt:~# wifi
command failed: Device or resource busy (-16)
Configuration file: /var/run/hostapd-phy0.conf
nl80211: Could not configure driver mode
nl80211 driver initialization failed.
hostapd_free_hapd_data: Interface gw00 wasn't started
hostapd_free_hapd_data: Interface gw00 wasn't started
hostapd_free_hapd_data: Interface sw00 wasn't started
Failed to start hostapd for phy0
command failed: Too many open files in system (-23)
command failed: Too many open files in system (-23)
command failed: Device or resource busy (-16)
Configuration file: /var/run/hostapd-phy1.conf
nl80211: Could not configure driver mode
nl80211 driver initialization failed.
hostapd_free_hapd_data: Interface gw10 wasn't started
hostapd_free_hapd_data: Interface sw10 wasn't started
Failed to start hostapd for phy1
root@cerowrt:~#

======== Wireless config file ====================

root@cerowrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'pci0000:00/0000:00:11.0'
	list ht_capab 'SHORT-GI-40'
	list ht_capab 'TX-STBC'
	list ht_capab 'RX-STBC1'
	list ht_capab 'DSSS_CCK-40'
	option channel '6'

config wifi-iface
	option device 'radio0'
	option network 'sw00'
	option ifname 'sw00'
	option mode 'ap'
	option ssid 'CEROwrt+'
	option key 'Beatthebloat'
	option encryption 'psk2'

config wifi-iface
	option device 'radio0'
	option network 'gw00'
	option mode 'ap'
	option ifname 'gw00'
	option ssid 'CEROwrt+guest'
	option key 'Beatthebloat'
	option encryption 'psk2'

config wifi-iface
	option device 'radio0'
	option network 'gw01'
	option ifname 'gw01'
	option mode 'adhoc'
	option ssid 'babel'
	option encryption 'none'

config wifi-device 'radio1'
	option type 'mac80211'
	option hwmode '11na'
	option path 'pci0000:00/0000:00:12.0'
	option htmode 'HT40+'
	list ht_capab 'SHORT-GI-40'
	list ht_capab 'TX-STBC'
	list ht_capab 'RX-STBC1'
	list ht_capab 'DSSS_CCK-40'
	option disabled '0'
	option channel '44'

config wifi-iface
	option device 'radio1'
	option network 'sw10'
	option ifname 'sw10'
	option mode 'ap'
	option ssid 'CEROwrt5+'
	option key 'Beatthebloat'
	option encryption 'psk2'

config wifi-iface
	option device 'radio1'
	option network 'gw10'
	option mode 'ap'
	option ifname 'gw10'
	option ssid 'CEROwrt+guest5'
	option key 'Beatthebloat'
	option encryption 'psk2'

config wifi-iface
	option device 'radio1'
	option network 'gw11'
	option ifname 'gw11'
	option mode 'adhoc'
	option ssid 'babel'
	option encryption 'none'

root@cerowrt:~#

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

[Dave Taht]

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.

> 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

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

[Sebastian Moeller]

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