Hi Dave,


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

> On Thu, Nov 14, 2013 at 11:36 AM, Richard E. Brown
> <richb.hano...@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: aqm.lua
Description: Binary data


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

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

Reply via email to