[Cerowrt-devel] if you can't tell

[Sebastian Moeller]

Hi Dave,



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

> On Thu, Nov 14, 2013 at 11:36 AM, Richard E. Brown
> <richb.hanover at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: aqm.lua
Type: application/octet-stream
Size: 4016 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20131117/ee42b70b/attachment-0002.obj>
-------------- next part --------------


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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel