[Cerowrt-devel] [Bloat] failing to find the "declared victory" in a current wifi router

Kevin Darbyshire-Bryant kevin at darbyshire-bryant.me.uk
Tue Jul 7 08:03:53 EDT 2015

Hi Joe (& everyone)

Joe, thanks for writing what you did, I really do feel your pain.  And
Rich's response is indeed superbly crafted & friendly, as is everyone's,
a credit to all.  I was a complete OpenWrt & SQM newbie around 3-4
months ago and found the website/documentation/sw situation/hw situation
bewildering!  <JOKE TONGUE-IN-CHEEK> I blame Jim Getty's & mostly Daht
Taht for stumbling across the bufferbloat rock (mountain!) lifting it up
to have a good look underneath...and not running away from what they
found </JOKE>  I probably watched every bufferbloat related presentation
I could find, read quite a few of the papers on 'codel', realised that
my internet connection was suffering from bufferbloat (shi**y latency
when doing uploads) and wanted to fix it.  That was the start of the
OpenWrt journey and not without frustrations :-)

I was advised that a TP-Link Archer C7 v2 was probably the best router
option available at the time that had sufficient horsepower for my 40/10
VDSL link (I was toying with 80/20 so wanted some processing headroom
too)  I also 'foolishly' went headlong into setting up an OpenWrt build
environment.  This caused a certain amount of pain, I went through a
very grumpy stage (Dave got an 'i've given up, I wish I'd never seen
openwrt/bufferbloat/sqm' email) *but* having your own build environment
has been the best thing *for me* - I can build my own firmware and not
rely on openwrt buildbots etc.  I don't hit kernel/module/package
incompatibilities because I build it all myself at the same time.

My own build environment has also allowed me to at least keep an eye on
the next generation of network queue management in the form of CAKE - I
barely understand a word of it, can't really test much, but I know I've
spotted a couple of bugs, contributed an idea into dnsmasq and dusted
off some very crusty 20+ year old unix admin awareness (reluctant to say

I've been meaning to document my experiences and offer some pointers
with regard to OpenWrt & the TP-Link C7 in a blog.  I seem to remember
offering to update http://www.bufferbloat.net/projects/codel/wiki/Cake
on how to get Cake into OpenWrt but didn't have edit access.  Both of
those personal projects stalled because I stumbled on a bug in OpenWrt's
feeds/package override functionality (now fixed) which made writing a
compact, sensible list of instructions impossible.  Really should resume
as things are a lot easier now.

I'd be happy to help you set up a build environment and offer some
pointers on how to use the OpenWrt build tools & feeds etc.  It's almost
fun (what *am* I saying :-)  I set up a Linux Mint 17.2 MATE install on
a teeny tiny Asus EeePC Netbook (with 748MB Ram!) a couple of days ago
and that (sloooowly) builds OpenWrt for me, so you don't need a
screaming edge machine by any means to do so.  Or you could use a
virtual machine environment:  I used virtualbox under windows on an i7
based laptop before I installed Linux Mint 17.2 Cinnamon as a dual
boot.....and then I trashed Windows entirely on the aforementioned
unused netbook.  I've been infected by Linux :-)

But I do understand your frustrations absolutely!  OpenWrt is not the
clearest thing out there.  There's quite a bit of terminology, jargon,
assumed knowledge on these lists which can be confusing.

Personal pet frustration: Lack of ADSL/VDSL capable OpenWrt hardware. 
Bonus extra pet frustration:  Those that exist (I thinks it's one
actually) don't support Byte Queue Limits (BQL) on the ADSL side of
things, so my dream of 'no knobs, auto configuration Smart Queue
Management (SQM)' for my parent's 2/0.4 M ADSL link remains a dream. 
Sigh.  But I'm slowly(!) learning source code version control with
'Git'.  I'm trying to learn a bit of 'C'.  And at some point I may
understand a little about the linux network code :-)

Please ask if you'd like some help.  It can be lonely out there.... I


On 07/07/15 08:20, Sebastian Moeller wrote:
> Hi Joe,
> I like your snark… And I like Rich’s elegant restraint in his response, always polite always friendly.
> On Jul 7, 2015, at 06:22 , Joe Touch <touch at isi.edu> wrote:
>> Hi, Rich,
>> On 7/6/2015 7:23 PM, Rich Brown wrote:
>>> Hi Joe,
>>> The OpenWrt firmware project is a "some assembly required" affair. 
>> That might be less daunting if there were assembly instructions. I.e.,
>> I'm suggesting that the instructions need revision. Work there could
>> have a significant payoff in a larger test community (I'm not exactly a
>> hardware noob, but I found it annoyingly obfuscated).
>>> Although it's not always easy to find, the site has a number of resources:
>>> 	- Buyer's Guide at http://wiki.openwrt.org/toh/buyerguide
>> That is useful for picking from among the currently supported versions,
>> but perhaps it'd be useful to take a colleague with you to a store and
>> see how helpful that all is. It's nearly impossible to find any of the
>> devices in the list or to verify whether a particular device in a box
>> has the required version of motherboard and firmware needed.
> 	I agree, it is almost inexcusable that the openwrt developers do/did not strong-arm all hardware vendors into sane product naming practices, like changing a products name when the interior parts change ;) Honestly though, no one is really happy about the current state of affairs I assume, but only the vendors are in a position to change this. So I applaud your insight, but think you should bring this specific discussion to the vendors...
>>> 	- The specific guidance to search Amazon for "OpenWrt" - see: http://amzn.to/1mONYr0
>> That turns up quite a bit of devices that aren't supported, FWIW.
>>> 	- The forum at: https://forum.openwrt.org/viewforum.php?id=10 mentions lots of routers
>> Indeed; more isn't better.
>>> As for specific routers:
>>> - The WNDR3800 remains our gold standard for CeroWrt builds. It'll
>>> do SQM up to ~30 mbps, then the CPU runs out of gas.
>> May I also suggest moving to another standard that hasn't been
>> explicitly "end-of-life'd" by the manufacturer.
> 	Sure, what would you recommend?
>>> - Check the OpenWrt Table of Hardware (ToH) to see what other routers
>>> support the current stable 14.07/Barrier Breaker (BB) builds.
>> Sure - I spent several days in Target, Best Buy, and Fry's trying to
>> decipher whether particular products were supported - again often
>> difficult without UPC numbers (boxes don't always indicate version)
> 	Yes, luckily many stores offer a no-questions-asked return policy, so that opening the box does not necessarily mean you have to buy it.
>>> - Many people on this list have good luck with the TP-Link Archer C7
>>> v2. I believe it'll route at cable speeds. I'm using it very
>>> successfully with OpenWrt BB release on a 7 mbps DSL line.
>> Here's a good example of how useful the information on the OpenWRT
>> website can be. Everyone seems to refer to this as "Archer C7", everyone
>> except the TP-Link website. Their search finds no products matching that
>> description, and the WIFI routers there are listed with other codes,
>> e.g.:TL-WDR7500 - except you won't find that number on the hardware page
>> -- you have to click through to the page for that device.
> 	Google is my friend, third link from googling “Archer C7 tp link":
> http://www.tp-link.com/en/products/details/cat-9_Archer-C7.html
> Again, to-link is not very consistent with its naming, but please take this fight to to-link, hoping that the openwrt/cerowrt crowd will be able to fix to-link’s site is a tad optimistic… 
>> For that device, like for many, the most recent version (i.e., the one
>> more likely to arrive on a blind web order, or on most store shelves) is
>> not yet supported.
>>> - If you have been following the Linksys WRT1900AC and WRT1200AC 
>>> thread at
>>> https://forum.openwrt.org/viewtopic.php?id=50173&action=newyou'll see
>>> that the CC builds are sorta, kinda working. There are a lot of moving
>>> pieces still, and despite the CC RC2 status, stable builds only come
>>> out a few days apart. I would stay away from it if you're not willing
>>> to participate in a science experiment.
>> Well, the 23-Apr-2015 build by Kaloz works fine - except that the SQM
>> package fails to install.
> 	What are the symptoms of that failure, if I might ask? 
>> What I'm baffled by here is that the main trunk builds leave LUCI out;
>> that's seems
>> quite short-sighted, IMO.
> 	I think the reasoning is that normal mortals should use stable releases like BB which come with luci by default, trunk is targeting people that can solve small issues like installing packages. That said, I would also prefer if luci or at least a GUI would be part of the trunk builds as well. One advantage of leaving luci and other non-essetials out is that the firmware image stays small enough to also work on flash starved devices...
>>> There is a team working to improve the OpenWrt site, but our work
>>> has not yet been "blessed" by the the admin's who maintain the core pages of
>>> the site.
>> And I appreciate and understand that. The CeroWRT site could similarly
>> use an update.
> 	Cerowrt basically ended or at least went into deep hibernation, the “declaring victory” news item (http://www.bufferbloat.net/news/) hints at that fact.
>> I.e., there's ample opportunity here to build a larger community with a
>> few simple steps:
>> 	- refer to routers by the manufacturer's designation
> 	But this is what confused you by no end above (well that fact that vendors change the hardware but keep the same name.
>> 	- create builds with both LUCI and (if possible) SQM
> 	So, normally if you install a trunk nightly build you should be able to install packages for that image at the same time. The next day the new nightly build will have replaced the one you installed, and that will make most/many/all? packages not install anymore. Is this maybe the failure case you have seen?
>> 	- make a short-list of a few currently available routers
>> 	for which an integrated build exists *for the most recent
>> 	motherboard version*
> 	Sure, that would be nice to have, for my taste the openwrt hardware wiki contains quite a lot in that direction. Unless vendors cooperate such a list will always be on a best effort basis, just as the current openwrt hardware wiki is.
>> All of this could be done on the CeroWRT site until it can be put on
>> OpenWRT.
> 	Since it seems we are into volunteering other folks here, all of this could also be done on your home page ;) I think I understand your indignation at the current state, the best way to remedy this is to roll up one’s sleeves and help fix things that do not work well.
> Best Regards
> 	Sebastian
>> These are fairly direct ways to lower the bar, which seems unnecessarily
>> high here.
>> Joe
>>> Best,
>>> Rich Brown
>>> On Jul 6, 2015, at 9:02 PM, Joe Touch <touch at isi.edu> wrote:
>>>> Hi, all,
>>>> I'm posting because of my recent frustration with the claim that
>>>> bufferbloat solutions have been "pushed up into the OpenWRT and
>>>> commercial routers.
>>>> I spent the bulk of last weekend trying to find a COTS WIFI router that
>>>> supported OpenWRT with bufferbloat (SQM) extensions.
>>>> I tried a Linksys WRT1200AC, and here's what I found:
>>>> 	- Kaloz's 23-Apr-2015 build installs fine and comes up
>>>> 	with a web server (LUCI), but does NOT include SQM
>>>> 		- trying to install the SQM packages fails
>>>> 		due to a kernel version incompatibility
>>>> 		(for a 23-Apr-2015 build?!)
>>>> 	- CC-rc2 doesn't have a WRT1200AC build
>>>> 	presumably I should have used mvebu-armada-385-linksys-caiman,
>>>> 	but it's not at all clear
>>>> 		- and I'd have to install LUCI and/or reinstall
>>>> 		factory firmware from the command line, and none
>>>> 		of that is all that clear, esp. a recovery route
>>>> 		that doesn't involve voiding warranty to wire in
>>>> 		a serial port
>>>> Given the "declared victory" (http://www.bufferbloat.net/news/53),
>>>> perhaps someone one one of these lists can explain why there's no clear
>>>> information on a current device that supports a current build that
>>>> actually supports these fixes?
>>>> I.e., if you were trying to make this obscure, you're doing a very good job.
>>>> FWIW.
>>>> Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4764 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20150707/43bcb538/attachment-0002.bin>

More information about the Cerowrt-devel mailing list