dave.taht at gmail.com
Wed Dec 19 11:17:59 EST 2012
Alex: it helps to subscribe to the list before posting.
On Sat, Dec 15, 2012 at 6:00 PM, Alex <halo2 at aon.at> wrote:
> Thanks for the nice project.
> Building like described at
> at least needs the diff added as attachment
> and a
> scripts/feeds install libgpgme
> (for opkg-gpg)
> so then a make menuconfig
> left then are undefined symbol
> still have to fix that
> pptp got ppp-mod-pptp and so its only luci-proto-ppp
> libcrypto is in libopenssl
> and also a kernel_menuconfig
Thank you for going through that. Not a lot of people try to build
cerowrt for themselves and I wish more did.
I note that the GPG support has been temporarily removed from the
Cerowrt-next development process pending coming up with something
lighter weight. I would like to put the patch back, actually, from
cerowrt-3.3.8, for now, but wanted time to think about alternatives
that could be used like something more purely openssl based.
> I think many of this things will be fixed in your environments? Or are
> they just old.
> Would be good for people who want to try it fast to apply my provided
> patch and propably an better config and kernel config?
> By the way, what brought me there is I'm searching for an easy way to geht
> the relevant buffer/queue changes into openwrt, as building this big
> release customized for one platform doesn't seem efficient to me for
> deploying and testing.
All you really have to do is add the debloat package to regular
openwrt. Switch it to use fq_codel. Solve for your bridges for your
underlying devices. Then check to see if you have BQL on your ethernet
devices and the queue depth on your adsl device.
Then run something like the rrul test at 10Mbit to make sure you got
all that right.
> Customized IP's, passwords dont make it easier too.
> So can you propably give little help on where the patchset I seek could be?
> It's an interesting topic and I like to test it.
> On my 2048/512 Kbit DSL only a few things seem to work as they should (yea
> got an wndr3800 for that), so using VMs and x86 seems a better approach
> for simulating by now.
VMs are useless for playing with bufferbloat. x86 has far, far, far
too many variables, like, for example, only about 10 drivers have BQL
It seems like you missed applying the simple_qos script rated for your
bandwidth, to your configuration. In your environment HTB is most
likely a must, unless your adsl modem supports ethernet pause frames.
> Ah, okay, just found http://snapon.lab.bufferbloat.net/~cero2/cerowrt/3.6/.
> Even x86 there as vmdk, very nice.
> Why dont post these links on the sites, and also for the build environment
> or so?
because the x86 vm build doesn't actually work yet. And has never
worked. Doesn't even boot. I'm extremely reluctant to support x86,
even in vm form because it's hard enough to get valid results and
experimentation out of one thoroughly debloated router.
The only use I have for having a vm lying around would be for gui
development. Which admittedly cerowrt could use some of, and I'm the
wrong guy to do it. My idea of a perfect user interface is:
sed -i s/172.30.42/172.30.43/g /etc/config/*
So I'm tickled you poked around and found stuff that I haven't
documented, but unless someone shows up that wants to build a vm of
cerowrt AND support it, I'm not heavily into the idea. By all means,
go for it, if you want.
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Cerowrt-devel