[Cerowrt-devel] if you can't tell

[Cerowrt-devel] if you can't tell

[Dave Taht]

I am simply horribly, horribly behind on email. I just got back from
canada day before yesterday and am trying to dig out. IETF was both
productive and non-productive in many ways...

was the consensus 3.10.18 was busted worse than 3.10.17? .19 is out
but I'll sink more time into it overall to solve various bugs
(sysupgrade via gui works? but not at the command line?) once and for
all, rather than
keep integrating

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] if you can't tell

[Sebastian Moeller]

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

Dave Taht <dave.taht@gmail.com> wrote:
>I am simply horribly, horribly behind on email. I just got back from
>canada day before yesterday and am trying to dig out. IETF was both
>productive and non-productive in many ways...
>
>was the consensus 3.10.18 was busted worse than 3.10.17? .19 is out
>but I'll sink more time into it overall to solve various bugs
>(sysupgrade via gui works? but not at the command line?) once and for
>all, rather than
>keep integrating
>
>--
>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

Hi Dave,
        I can not offer a useful opinion, since I updated from 3.10.11-2. But for me it seems to work, but I have not yet done thorough testing... Yes sysupgrade from the command line gets stuck while update from the GUI works. Once I find the I want to figure out what is different between these two, but no ETA for that from me. What about just documenting to either use mtd or the GUI and consider this sufficiently worked around?

Best Regards
      Sebastian



--


[-- Attachment #2: Type: text/html, Size: 1294 bytes --]

Re: [Cerowrt-devel] if you can't tell

[Richard E. Brown]

Dave,

The flurry of comments on 3.10.18 that I posted were partially caused because I used sysupgrade (the first time ever! Previously, I had used tftp.) and I think some problems were caused because I kept the configuration. I’m looking for a bit of time to re-flash, this time not keeping the configs and running my config.sh script to set things up. 

Rich

PS I don’t see a 3.10.19 posted on http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/ yet.


On Nov 14, 2013, at 2:04 PM, Dave Taht <dave.taht@gmail.com> wrote:

> I am simply horribly, horribly behind on email. I just got back from
> canada day before yesterday and am trying to dig out. IETF was both
> productive and non-productive in many ways...
> 
> was the consensus 3.10.18 was busted worse than 3.10.17? .19 is out
> but I'll sink more time into it overall to solve various bugs
> (sysupgrade via gui works? but not at the command line?) once and for
> all, rather than
> keep integrating
> 
> -- 
> 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

Re: [Cerowrt-devel] if you can't tell

[Dave Taht]

On Thu, Nov 14, 2013 at 11:36 AM, Richard E. Brown
<richb.hanover@gmail.com> wrote:
> Dave,
>
> The flurry of comments on 3.10.18 that I posted were partially caused because I used sysupgrade (the first time ever! Previously, I had used tftp.) and I think some problems were caused because I kept the configuration. I’m looking for a bit of time to re-flash, this time not keeping the configs and running my config.sh script to set things up.
>
> Rich
>
> PS I don’t see a 3.10.19 posted on http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/ yet.

You guys are so eager to subject yourselves to new releases! take a
weekend off! It's lovely in california right now...

I didn't see anything in 3.10.19 that is truly needed right now. there
is some good work being done on fixing random number generation in the
mainline, dnsmasq has an update, pie is 99.999999999% ready for
mainline, but there's nothing I can do to push those faster...

and I am ashamed to admit that the big reason why I haven't dug in to
fix sysupgrade was because I haven't cleaned up the yurt in a while.
Somewhere in it is buried the bus pirate

http://dangerousprototypes.com/docs/Bus_Pirate

that I need to get to the serial port to get to see what the heck is
going wrong at the command line. So I'm going to shovel out and reorg
the place while the weather is good and hopefully that will show up.

I have a feature request for the aqm gui - in that many fields don't
need to be exposed if the encapsulation is ethernet. I fear in making
the dsl users happy we will confuse the others.

What other open questions do we have?

Firewall rules good?
minissd working?
upnp working?



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] if you can't tell

[Sebastian Moeller]

Hi Dave,


On Nov 14, 2013, at 20:57 , Dave Taht <dave.taht@gmail.com> wrote:

> On Thu, Nov 14, 2013 at 11:36 AM, Richard E. Brown
> <richb.hanover@gmail.com> wrote:
>> Dave,
>> 
>> The flurry of comments on 3.10.18 that I posted were partially caused because I used sysupgrade (the first time ever! Previously, I had used tftp.) and I think some problems were caused because I kept the configuration. I’m looking for a bit of time to re-flash, this time not keeping the configs and running my config.sh script to set things up.
>> 
>> Rich
>> 
>> PS I don’t see a 3.10.19 posted on http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/ yet.
> 
> You guys are so eager to subject yourselves to new releases! take a
> weekend off! It's lovely in california right now…

	;) it happens to be cold wet and foggy in Germany, a really nice autumn as it should be in that part of the world, but I sure miss California (I always loved how the rain season made SoCal green again) 

> 
> I didn't see anything in 3.10.19 that is truly needed right now. there
> is some good work being done on fixing random number generation in the
> mainline, dnsmasq has an update, pie is 99.999999999% ready for
> mainline, but there's nothing I can do to push those faster...
> 
> and I am ashamed to admit that the big reason why I haven't dug in to
> fix sysupgrade was because I haven't cleaned up the yurt in a while.
> Somewhere in it is buried the bus pirate
> 
> http://dangerousprototypes.com/docs/Bus_Pirate
> 
> that I need to get to the serial port to get to see what the heck is
> going wrong at the command line. So I'm going to shovel out and reorg
> the place while the weather is good and hopefully that will show up.
> 
> I have a feature request for the aqm gui - in that many fields don't
> need to be exposed if the encapsulation is ethernet. I fear in making
> the dsl users happy we will confuse the others.

	Okay, unless more skilled hands take this over, I will have a go at this (most likely next week, as I expect visitors over the weekend). Interestingly are all options also valid for ethernet, so what about putting all those commands on a second tab that it easier to ignore? Anyway, I see what I can do...

> 
> What other open questions do we have?
> 
> Firewall rules good?
> minissd working?
> upnp working?

	I have not yet tested anything in particular, but then I see no problems either, so my (current) take is 3.11.18 is a keeper :)

Best Regards & enjoy the weekend
	Sebastian


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

Re: [Cerowrt-devel] if you can't tell

[Sebastian Moeller]

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

Hi Dave,



On Nov 14, 2013, at 20:57 , Dave Taht <dave.taht@gmail.com> wrote:

> On Thu, Nov 14, 2013 at 11:36 AM, Richard E. Brown
> <richb.hanover@gmail.com> wrote:
>> Dave,
>> 
>> The flurry of comments on 3.10.18 that I posted were partially caused because I used sysupgrade (the first time ever! Previously, I had used tftp.) and I think some problems were caused because I kept the configuration. I’m looking for a bit of time to re-flash, this time not keeping the configs and running my config.sh script to set things up.
>> 
>> Rich
>> 
>> PS I don’t see a 3.10.19 posted on http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/ yet.
> 
> You guys are so eager to subject yourselves to new releases! take a
> weekend off! It's lovely in california right now...
> 
> I didn't see anything in 3.10.19 that is truly needed right now. there
> is some good work being done on fixing random number generation in the
> mainline, dnsmasq has an update, pie is 99.999999999% ready for
> mainline, but there's nothing I can do to push those faster...
> 
> and I am ashamed to admit that the big reason why I haven't dug in to
> fix sysupgrade was because I haven't cleaned up the yurt in a while.
> Somewhere in it is buried the bus pirate

	So this is weird, but I noticed that we have a mount binary in /usr/bin that seems to be earlier in our path than busy box's /bin/mount. So I just went and replaced all "mount" invocations in /lib/upgrade/common.sh with "busy box mount" and that seems to have done the trick (it upgraded and rebooted into a pristine 3.10.18-1, I am not sure whether the firmware partition was really overwritten, but the overlay partition surely was wiped). It seems that the option handling of /usr/bin/mount chokes on the actual mount invocations in that script (I noticed that the move of /proc failed and from then on it was downhill). I am not sure whether my modification to common.sh is not too ugly to live, but I assume that the grown-ups ail find a proper way to fix this now :) And what I currently do not understand is why the GUI method worked since that is just calling the sys upgrade script from "/"...


> 
> http://dangerousprototypes.com/docs/Bus_Pirate
> 
> that I need to get to the serial port to get to see what the heck is
> going wrong at the command line. So I'm going to shovel out and reorg
> the place while the weather is good and hopefully that will show up.
> 
> I have a feature request for the aqm gui - in that many fields don't
> need to be exposed if the encapsulation is ethernet. I fear in making
> the dsl users happy we will confuse the others.

So I had a quick go at this one:
Please put the attached file 
/usr/lib/lua/luci/model/cbi/aqm.lua


[-- Attachment #2: aqm.lua --]
[-- Type: application/octet-stream, Size: 4016 bytes --]

--[[
LuCI - Lua Configuration Interface

Copyright 2008 Steven Barth <steven@midlink.org>

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

	http://www.apache.org/licenses/LICENSE-2.0

$Id$
]]--

local wa = require "luci.tools.webadmin"
local fs = require "nixio.fs"
local net = require "luci.model.network".init()
local ifaces = net:get_interfaces()
local path = "/usr/lib/aqm"

m = Map("aqm", translate("Active Queue Management"),
	translate("With <abbr title=\"Active Queue Management\">AQM</abbr> you " ..
		"can enable traffic shaping and prioritisation on one or more " ..
		"network interfaces."))

s = m:section(TypedSection, "queue", translate("Queues"))
s.addremove = true
s.anonymous = true

n = s:option(ListValue, "interface", translate("Interface name"))
for _, iface in ipairs(ifaces) do
     if iface:is_up() then
	n:value(iface:name())
     end
end
n.rmempty = false


e = s:option(Flag, "enabled", translate("Enable"))
e.rmempty = false

c = s:option(ListValue, "qdisc", translate("Queueing discipline"))
c:value("fq_codel", "fq_codel ("..translate("default")..")")
c:value("efq_codel")
c:value("nfq_codel")
c:value("sfq")
c:value("codel")
c:value("ns2_codel")
c:value("pie")
c:value("sfq")
c.default = "fq_codel"
c.rmempty = false

local qos_desc = ""
sc = s:option(ListValue, "script", translate("Queue setup script"))
for file in fs.dir(path) do
  if string.find(file, ".qos$") then
    sc:value(file)
  end
  if string.find(file, ".qos.help$") then
    fh = io.open(path .. "/" .. file, "r")
    qos_desc = qos_desc .. "<p><b>" .. file:gsub(".help$", "") .. ":</b><br />" .. fh:read("*a") .. "</p>"
  end
end
sc.default = "simple.qos"
sc.rmempty = false
sc.description = qos_desc

dl = s:option(Value, "download", translate("Download speed (kbit/s)"))
dl.datatype = "and(uinteger,min(1))"
dl.rmempty = false

ul = s:option(Value, "upload", translate("Upload speed (kbit/s)"))
ul.datatype = "and(uinteger,min(1))"
ul.rmempty = false

lla = s:option(ListValue, "linklayer_adaptation_mechanism", translate("Which linklayer adaptation mechanism to use; especially useful for ADSL/ATM links.")) -- Creates an element list (select box)
lla:value("none")
lla:value("htb_private")
lla:value("tc_stab")
lla.default = "none"

ll = s:option(ListValue, "linklayer", translate("Which linklayer to account for")) -- Creates an element list (select box)
ll:value("ethernet")
ll:value("adsl")
ll:value("atm")
ll.default = "ethernet"
ll:depends("linklayer_adaptation_mechanism", "htb_private")
ll:depends("linklayer_adaptation_mechanism", "tc_stab")

po = s:option(Value, "overhead", translate("Per Packet Overhead (byte)"))
po.datatype = "and(integer,min(-1500))"
po.default = 0
po.isnumber = true
po.rmempty = false
po:depends("linklayer_adaptation_mechanism", "htb_private")
po:depends("linklayer_adaptation_mechanism", "tc_stab")

smtu = s:option(Value, "MTU", translate("Maximal Size for size and rate calculations (byte) (tc MTU), needs to be >= interface MTU"))
smtu.datatype = "and(uinteger,min(0))"
smtu.default = 2047
smtu.isnumber = true
smtu.rmempty = false
smtu:depends("linklayer_adaptation_mechanism", "htb_private")
smtu:depends("linklayer_adaptation_mechanism", "tc_stab")

stsize = s:option(Value, "TSIZE", translate("Number of entries in size/rate tables, for ATM choose TSIZE = (MTU + 1) / 16"))
stsize.datatype = "and(uinteger,min(0))"
stsize.default = 128
stsize.isnumber = true
stsize.rmempty = false
stsize:depends("linklayer_adaptation_mechanism", "htb_private")
stsize:depends("linklayer_adaptation_mechanism", "tc_stab")

smpu = s:option(Value, "MPU", translate("Minimal packet size (byte); needs to be >0 for ethernet size tables"))
smpu.datatype = "and(uinteger,min(0))"
smpu.default = 0
smpu.isnumber = true
smpu.rmempty = false
smpu:depends("linklayer_adaptation_mechanism", "htb_private")
smpu:depends("linklayer_adaptation_mechanism", "tc_stab")


return m

[-- Attachment #3: Type: text/plain, Size: 786 bytes --]



this should hide all confusing fields until htb_private or tc_stab are selected under the field named:
Which linklayer adaptation mechanism to use; especially useful for ADSL/ATM links.

So "none" will hide all the cruft. Since most of the options also can work with ethernet links (think PPPoE on a non-ATM carrier will still cause an 8 byte per packet overhead).



> 
> What other open questions do we have?
> 
> Firewall rules good?
> minissd working?
> upnp working?
> 
> 
> 
> -- 
> 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

Re: [Cerowrt-devel] if you can't tell

[Fred Stratton]

[-- Attachment #1.1: Type: text/plain, Size: 1003 bytes --]




-------- Original Message --------
Subject: 	Re: [Cerowrt-devel] if you can't tell
Date: 	Thu, 14 Nov 2013 19:20:36 +0000
From: 	Fred Stratton <fredstratton@ydl.net>
To: 	cerowrt-devel@lists.bufferbloat.net






-------- Original Message --------
Subject: 	Re: [Cerowrt-devel] if you can't tell
Date: 	Thu, 14 Nov 2013 19:19:50 +0000
From: 	Fred Stratton <fredstratton@imap.cc>
To: 	Dave Taht <dave.taht@gmail.com>



Speaking as one data point, I like 3.10.18. It works quite well with
ADSL2plus.

I shall try 3.10.19.

On 14/11/13 19:04, Dave Taht wrote:
> I am simply horribly, horribly behind on email. I just got back from
> canada day before yesterday and am trying to dig out. IETF was both
> productive and non-productive in many ways...
>
> was the consensus 3.10.18 was busted worse than 3.10.17? .19 is out
> but I'll sink more time into it overall to solve various bugs
> (sysupgrade via gui works? but not at the command line?) once and for
> all, rather than
> keep integrating
>






[-- Attachment #1.2: Type: text/html, Size: 3349 bytes --]

[-- Attachment #2: Attached Message Part --]
[-- Type: text/plain, Size: 165 bytes --]

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

Re: [Cerowrt-devel] if you can't tell

[Fred Stratton]

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




-------- Original Message --------
Subject: 	Re: [Cerowrt-devel] if you can't tell
Date: 	Thu, 14 Nov 2013 19:19:50 +0000
From: 	Fred Stratton <fredstratton@imap.cc>
To: 	Dave Taht <dave.taht@gmail.com>



Speaking as one data point, I like 3.10.18. It works quite well with
ADSL2plus.

I shall try 3.10.19.

On 14/11/13 19:04, Dave Taht wrote:
> I am simply horribly, horribly behind on email. I just got back from
> canada day before yesterday and am trying to dig out. IETF was both
> productive and non-productive in many ways...
>
> was the consensus 3.10.18 was busted worse than 3.10.17? .19 is out
> but I'll sink more time into it overall to solve various bugs
> (sysupgrade via gui works? but not at the command line?) once and for
> all, rather than
> keep integrating
>




[-- Attachment #2: Type: text/html, Size: 1912 bytes --]