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

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

[Rich Brown]

Hi Joe,

The OpenWrt firmware project is a "some assembly required" affair. 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
	- The specific guidance to search Amazon for "OpenWrt" - see: http://amzn.to/1mONYr0
	- The forum at: https://forum.openwrt.org/viewforum.php?id=10 mentions lots of routers

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.
	- Check the OpenWrt Table of Hardware (ToH) to see what other routers support the current stable 14.07/Barrier Breaker (BB) builds. 
	- 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.
	- If you have been following the Linksys WRT1900AC and WRT1200AC thread at https://forum.openwrt.org/viewtopic.php?id=50173&action=new you'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.

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.

Best,

Rich Brown

On Jul 6, 2015, at 9:02 PM, Joe Touch <touch@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
> 
> 
> 
> 	
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[Sebastian Moeller]

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

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

[Kevin Darbyshire-Bryant]

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

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
skills!)

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
*know*!

Kevin



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



[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4764 bytes --]

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

[Rich Brown]

Hi Joe,

These are great observations. CeroWrt was boosted enormously by the presence of the powerful and reliable OpenWrt software platform. We were able to make so much progress with bufferbloat because OpenWrt provided a stable platform for our experiments. Nonetheless, the motivations of the two teams - CeroWrt and OpenWrt - are vastly different, and I offer the following to help you adjust your expectations.

- CeroWrt was, and remains, a research project for "making networking better". In 2012, this team of open-source developers solved the problem of bufferbloat. (Hardly any other commercial or academic development group even understood or acknowledged there was a problem.) Now the team is moving on to other projects, including "making wifi fast" (again, this does not seem to be addressed by any commercial/academic groups). We continue our work with CeroWrt, using a current version of OpenWrt as the base. The Bufferbloat/CeroWrt site has attracted a significant following of people who're willing to test the bleeding edge of network research. The current builds make no promises of reliability (or even functionality), but it's fun to hang out with people who're driving science forward.

- I'm a newcomer to OpenWrt, but it seems that their mission is to make the OpenWrt software run on as many different devices/routers as possible. This has a side benefit of making the excellent OpenWrt software available on a number of excellent routers, which, as a second-order side benefit might be useful to make the network better at your home. As far as I can tell, making it easier to learn about, install, and run OpenWrt is not a primary goal. Furthermore, the OpenWrt leaders are reluctant to recommend any particular piece of equipment, to avoid accusations of "favoritism". That said, I'm working with a number of people to improve the resources at OpenWrt to pull all the info together so that people can get the benefits of OpenWrt without having to read 10,000 forum posts and wiki pages.

With that framework in mind, let me respond to your questions.

TL;DR - if you just want to fix your home network today and get on with your life, I recommend:
	- OpenWrt Barrier Breaker (BB) release. As of July 2015, it's the stable version. Stay away from CC or trunk, as they're still evolving.
	- Install OpenWrt using the instructions at: http://wiki.openwrt.org/doc/howto/installopenwrt
	- Install SQM/fq_codel  to solve bufferbloat using the instructions at: http://wiki.openwrt.org/doc/howto/sqm
	- What router to choose? I bought the TP-Link Archer C7 v2 for ~$90 (US). http://wiki.openwrt.org/toh/tp-link/tl-wdr7500 In a one-out-of-one test, it seems to work well with BB, SQM works fine, and I'm happy.

On Jul 7, 2015, at 12:22 AM, Joe Touch <touch@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).

Yup. I agree. 

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

Yup.

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

Yup. That's why I'm on the team to improve documentation... We will have a delicate balance between the project founders' reluctance to recommend any devices and the desire help people "just to get something going".

>> 	- The forum at: https://forum.openwrt.org/viewforum.php?id=10 mentions lots of routers
> 
> Indeed; more isn't better.

Yup.

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

The CeroWrt team (Thanks, Dave!) is working hard to find a replacement for the WNDR3800 that will handle higher speeds. Read the cerowrt-devel list frequently (daily?) to follow that news. We'll update the CeroWrt site once there's a good recommendation. 

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

I don't ever expect OpenWrt to include UPC info. It's hard enough to get the user-maintained wiki to have accurate info at all. (And vendors change UPC's all the time... See the next point.)

Better to read (and ask) for information on the forums.

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

Blame TP-Link for this confusion. The box may mention "WDR7500" (I've thrown mine away so I can't check), but neither the router nor the TP-Link website (today) mentions "WDR7500". The label on my router says "Model: Archer C7"

Does this situation stink out loud? Yes. But it's not ours to fix.

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

Yup. Welcome to software that's under development. You should definitely follow the OpenWrt forum thread on 1900AC. https://forum.openwrt.org/viewtopic.php?id=50173&p=246

> What I'm baffled by here is that the main trunk builds leave LUCI out;
> that's seems
> quite short-sighted, IMO.

That may be an explicit decision. I believe, without authoritative confirmation, that the GUI is not included in trunk builds as a means to "scare away the beginners". I would argue that it has the opposite effect - that of causing more confusion. But I'm not driving that bus. 

A page that describes the trunk builds as being suitable only for people who are willing to work with buggy, unreliable, and had-to-use builds would be valuable. (That's why I'm on the team to improve documentation...)

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

With CeroWrt, we need to split our time between fixing and enhancing the software and telling the world about it. It has been a while since we've reviewed the Bufferbloat.net site with an eye toward a newcomer, and I can do that. 

> I.e., there's ample opportunity here to build a larger community with a
> few simple steps:

As I stated above, it's not clear to me that building a community of people who *use* the software is foremost in the core developers' minds at OpenWrt. That said,

> 	- refer to routers by the manufacturer's designation
> 	- create builds with both LUCI and (if possible) SQM
> 	- make a short-list of a few currently available routers
> 	for which an integrated build exists *for the most recent
> 	motherboard version*

Within the limitations of a user-maintained wiki, that's why I'm on the team to improve documentation...
> 
> All of this could be done on the CeroWRT site until it can be put on
> OpenWRT.

No. The two teams - and goals - are separate. Although I'm playing both sides of the street, I still don't want to post stuff on the CeroWrt site that needs to be updated when things get better on the OpenWrt site. 

> These are fairly direct ways to lower the bar, which seems unnecessarily
> high here.

Yup. That's why I'm on the team to improve documentation...

Rich

>> 
>> On Jul 6, 2015, at 9:02 PM, Joe Touch <touch@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
>>> 
>>> 
>>> 
>>> 	
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 

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

[Rich Brown]

Matt,

This is useful. I will review this and give you comments, and ensure any additional knowledge makes it into the OpenWrt HOWTO's. Thanks.

Rich

On Jul 7, 2015, at 2:19 PM, Matt Taggart <matt@lackof.org> wrote:
> 
> This message made me realize I hadn't posted the CC+SQM HOWTO I wrote, 
> maybe it will be useful,
> 
> https://we.riseup.net/lackof/openwrt
> 
> Feedback welcome.
> 
> -- 
> Matt Taggart
> matt@lackof.org
> 
> 

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

[Sebastian Moeller]

Hi Joe,

On Jul 8, 2015, at 20:37 , Joe Touch <touch@isi.edu> wrote:

> Hi, Matt,
> 
> On 7/7/2015 11:19 AM, Matt Taggart wrote:...
>> This message made me realize I hadn't posted the CC+SQM HOWTO I
>> wrote, maybe it will be useful,
>> 
>> https://we.riseup.net/lackof/openwrt
> 
> FWIW, this is a big step in the direction I was suggesting.
> 
> Thanks!
> 
> The other step, IMO, would be two flags in the OpenWRT list of hardware:
> 
> 	- a flag/color that indicates that the most recent hardware rev
> 	supports BB
> 
> 	- a different flag/color that indicates that the most recent
> 	hardware rev supports CC

	If you look at http://wiki.openwrt.org/toh/start you should have noticed two columns: version and status:
status was/is supposed from which version openwrt supports that specific router
version is supposed to tell which versions of said router actually fall under the supported status. 
Granted, status are not filled for all routers and sometimes with the unfortunate label “trunk” without stating a date or release number, but these seem to be the minority. Versionseems to be in worse shape with lots of “-“ and “?”. 
	By the way, you keep repeating the phrase “most recent hardware rev.” as if there was a common repository somewhere on the web from which to deduce what the most recent incarnation of each specific router name/type is; as it stands this information is filled in by volunteers, based on what version they got from a store/vendor/OEM and their installation testing/development. 
	I would love to learn if you have a better way of collecting that information preferably in an automated fashion?

> 
> The current list is a confusing mix of information about very old,
> sometimes EOL (end-of-life) equipment.

        What is bad about keeping information? Just because a device is EOL by its manufacturer/vendor does not necessarily mean it is completely out of the retail channel/ second hand retail/sharing channel, so keeping information how to give such devices a “second life” as openwrt routers seems like a good idea to me.

> 
> To those who have invited me to participate in the research, thanks, but
> sometimes I just want to *use* a solution.

	Fair enough. I noticed I might seem a bit grumpy, not sure why but I would blame it on the weird weather here...

Best Regards
	Sebastian


> I'm OK with a buggy,
> partially unstable one, but I don't always want to dive into
> developer-mode for every system I'd like to test out.
> 
> Joe
> 
> 
> 
> 
> 
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[Sebastian Moeller]

Hi Joe,

On Jul 8, 2015, at 22:28 , Joe Touch <touch@isi.edu> wrote:

> Hi, Sebastian,
> 
> On 7/8/2015 1:15 PM, Sebastian Moeller wrote:
>> Hi Joe,
>> 
>> On Jul 8, 2015, at 20:37 , Joe Touch <touch@isi.edu> wrote:
> ...
>>> The other step, IMO, would be two flags in the OpenWRT list of hardware:
>>> 
>>> 	- a flag/color that indicates that the most recent hardware rev
>>> 	supports BB
>>> 
>>> 	- a different flag/color that indicates that the most recent
>>> 	hardware rev supports CC
>> 
>> If you look at http://wiki.openwrt.org/toh/start you should have
>> noticed two columns: version and status: status was/is supposed from
>> which version openwrt supports that specific router version is
>> supposed to tell which versions of said router actually fall under
>> the supported status.
> 
> The information isn't clear:
> 
> 	- does this indicate the openwrt version that first supported
> 	the hardware? or the specific version that is required?

	Actually both; I assume it to be the openwrt revision under which the device worked initially. Hopefully this also means that revision or newer, but unless its popular hardware it might not be tested at all with more recent revisions and hence might have regressed back into non-working territory.

> 
> 	- for devices with multiple versions, this doesn't
> 	indicate whether the most recent version is supported or
> 	if the information refers to legacy versions

	Unless you come up with a sure fire way to figure out the “most recent version” this line of argument is leading nowhere, fast ;) But if you follow the link that does doubly duty as the model name in the wiki you end up on the model specific web site that often gives exactly the information you here require, which hardware revision started working with which openwrt revision. Then again often enough even the detailed version stays silent on this topic. A subtle call to action for user’s of that device ;)

> 
>> Granted, status are not filled for all routers and sometimes with the
>> unfortunate label “trunk” without stating a date or release number,
>> but these seem to be the minority. Version seems to be in worse shape
>> with lots of “-“ and “?”.
> 
>> By the way, you keep repeating the phrase “most recent hardware rev.”
>> as if there was a common repository somewhere on the web from which
>> to deduce what the most recent incarnation of each specific router
>> name/type is; as it stands this information is filled in by
>> volunteers, based on what version they got from a store/vendor/OEM
>> and their installation testing/development. I would love to learn if
>> you have a better way of collecting that information preferably in an
>> automated fashion?
> 
> Sorry; to be more clear, I'm only asking for a different way of seeing
> the information already on the site.
> 
> E.g., the Linksys WNDR4300 indicates support for v1 under BB, but that's
> not the version that's now sold; when I click through to the device page
> I see the information that indicates that the most recent motherboard
> version is not currently supported at all.

	Let me be pedantic, the most recent version documented in the wiki, there might be a v3 out there somewhere and we just do not know yet.

> 
> I.e., I would have found the table much more useful if it had indicated:
> 
> device		BB	CC	highest board rev/support
> -------------------------------------------------
> WNDR4300	V1	no	V2/no
> 
> The BB column would tell me whether BB works and on what revs (and could
> list more than one board rev); similarly for the CC column.

	And that is a loosing proposition on a wiki maintained by volunteers; as you have indicated yourself the amount of time people are willing to invest in something like a hardware wiki is pretty small, not necessarily for occasional “spring cleaning” like it is happening now, but rather the small maintenance work of keep adding new revisions once they are discovered. Also what about DD, and the most likely following EE… the table gains columns quickly that way ;)

> 
> The last column above would tell me whether to bother trying to buy this
> device now.

	You assume that the retail channel only carries the most recent version, do you? Which is unfortunately not true…

> 
> All this information could be derived by clicking on the many devices in
> the list; I'm suggesting a different organization that would be more
> useful to those trying to get on board and join the project.

	I believe you will be quite happy once the changes to the ToH wiki page that are currently in midair land on the wiki; as far as I can see a lot of that reorganization is happening. If you want to contribute your insight and expertise have a look at the following thread: https://forum.openwrt.org/viewtopic.php?id=56521 …

> 
>>> The current list is a confusing mix of information about very old,
>>> sometimes EOL (end-of-life) equipment.
>> 
>> What is bad about keeping information? Just because a device is EOL 
>> by its manufacturer/vendor does not necessarily mean it is completely
>> out of the retail channel/ second hand retail/sharing channel, so
>> keeping information how to give such devices a “second life” as
>> openwrt routers seems like a good idea to me.
> 
> Nothing is wrong with keeping the info; the issue is whether and when to
> push it to a separate page.

	Never? Just make the whole thing filterable, which I believe is being prototyped as we speak ;)

> 
> Again, I do hope the feedback is useful.

	I have a hunch it would be even more useful if voiced in a way the openwrt developers/documenters community could actually see your ideas… (as far as I know Rich Brown is the only one here working on improving the openwrt wiki (and I am really glad he is doing it as I like his documentation a lot, but I digress))

Best Regards
	Sebastian

> 
> Joe

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

[Rich Brown]

Thanks all for the comments. Sebastian has indicated our direction well. Here are more details about our process for making the Table of Hardware less inscrutable.

We are updating the Table of Hardware (ToH) of the OpenWrt wiki to be generated from a series of "Technical data" templates. We have already scraped the info from the current ToH into separate Technical Data templates for each of the routers listed there (~912 of them). When we're done, this will have the following benefits:

- There can be multiple ToH's. Obviously, there will be the main one with a selection of columns that show the most important info for the general reader. We can also have a "Supported in Current Release" ToH, a WIP ToH, a "Last Supported Release was Attitude Adjustment" ToH, etc.
- People update the info in the template when they learn more. That info automagically flows into all the ToH's
- In addition, the information from the Technical Detail pages can go into a router's "Details Page". The maintainer can add one or more "datatable"s that select fields from Technical Data templates, and display the info as a table in a router's details page. 
- Each router's info will need to be maintained. If nobody updates the technical data to indicate the router works with the (soon to be released) CC, then that router will automatically fall out of the "Supported in Current Release" ToH. 

I wish we were a couple weeks farther along so you could see it in action. (We have a prototype running now, but we're reluctant to open it to the world, as it's running on a RPi :-) You can view the current fields we have identified for the Technical Data template at: http://wiki.openwrt.org/toh/dataentry_template

We could use some help:

a) Please review the Technical Data template's fields, and let us know if any are not clear.

b) If you're terminally curious about or thoughts/process, you can read the forum thread (!) at https://forum.openwrt.org/viewtopic.php?pid=282707

c) We need some help from OpenWrt admins to make some progress. I have a ticket filed on dev.openwrt.org for three weeks with no response, and an email to an admin outstanding for two weeks. Does anyone know a good way to contact them? Thanks.

Rich


On Jul 8, 2015, at 6:16 PM, Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi Joe,
> 
> On Jul 8, 2015, at 22:28 , Joe Touch <touch@isi.edu> wrote:
> 
>> Hi, Sebastian,
>> 
>> On 7/8/2015 1:15 PM, Sebastian Moeller wrote:
>>> Hi Joe,
>>> 
>>> On Jul 8, 2015, at 20:37 , Joe Touch <touch@isi.edu> wrote:
>> ...
>>>> The other step, IMO, would be two flags in the OpenWRT list of hardware:
>>>> 
>>>> 	- a flag/color that indicates that the most recent hardware rev
>>>> 	supports BB
>>>> 
>>>> 	- a different flag/color that indicates that the most recent
>>>> 	hardware rev supports CC
>>> 
>>> If you look at http://wiki.openwrt.org/toh/start you should have
>>> noticed two columns: version and status: status was/is supposed from
>>> which version openwrt supports that specific router version is
>>> supposed to tell which versions of said router actually fall under
>>> the supported status.
>> 
>> The information isn't clear:
>> 
>> 	- does this indicate the openwrt version that first supported
>> 	the hardware? or the specific version that is required?
> 
> 	Actually both; I assume it to be the openwrt revision under which the device worked initially. Hopefully this also means that revision or newer, but unless its popular hardware it might not be tested at all with more recent revisions and hence might have regressed back into non-working territory.
> 
>> 
>> 	- for devices with multiple versions, this doesn't
>> 	indicate whether the most recent version is supported or
>> 	if the information refers to legacy versions
> 
> 	Unless you come up with a sure fire way to figure out the “most recent version” this line of argument is leading nowhere, fast ;) But if you follow the link that does doubly duty as the model name in the wiki you end up on the model specific web site that often gives exactly the information you here require, which hardware revision started working with which openwrt revision. Then again often enough even the detailed version stays silent on this topic. A subtle call to action for user’s of that device ;)
> 
>> 
>>> Granted, status are not filled for all routers and sometimes with the
>>> unfortunate label “trunk” without stating a date or release number,
>>> but these seem to be the minority. Version seems to be in worse shape
>>> with lots of “-“ and “?”.
>> 
>>> By the way, you keep repeating the phrase “most recent hardware rev.”
>>> as if there was a common repository somewhere on the web from which
>>> to deduce what the most recent incarnation of each specific router
>>> name/type is; as it stands this information is filled in by
>>> volunteers, based on what version they got from a store/vendor/OEM
>>> and their installation testing/development. I would love to learn if
>>> you have a better way of collecting that information preferably in an
>>> automated fashion?
>> 
>> Sorry; to be more clear, I'm only asking for a different way of seeing
>> the information already on the site.
>> 
>> E.g., the Linksys WNDR4300 indicates support for v1 under BB, but that's
>> not the version that's now sold; when I click through to the device page
>> I see the information that indicates that the most recent motherboard
>> version is not currently supported at all.
> 
> 	Let me be pedantic, the most recent version documented in the wiki, there might be a v3 out there somewhere and we just do not know yet.
> 
>> 
>> I.e., I would have found the table much more useful if it had indicated:
>> 
>> device		BB	CC	highest board rev/support
>> -------------------------------------------------
>> WNDR4300	V1	no	V2/no
>> 
>> The BB column would tell me whether BB works and on what revs (and could
>> list more than one board rev); similarly for the CC column.
> 
> 	And that is a loosing proposition on a wiki maintained by volunteers; as you have indicated yourself the amount of time people are willing to invest in something like a hardware wiki is pretty small, not necessarily for occasional “spring cleaning” like it is happening now, but rather the small maintenance work of keep adding new revisions once they are discovered. Also what about DD, and the most likely following EE… the table gains columns quickly that way ;)
> 
>> 
>> The last column above would tell me whether to bother trying to buy this
>> device now.
> 
> 	You assume that the retail channel only carries the most recent version, do you? Which is unfortunately not true…
> 
>> 
>> All this information could be derived by clicking on the many devices in
>> the list; I'm suggesting a different organization that would be more
>> useful to those trying to get on board and join the project.
> 
> 	I believe you will be quite happy once the changes to the ToH wiki page that are currently in midair land on the wiki; as far as I can see a lot of that reorganization is happening. If you want to contribute your insight and expertise have a look at the following thread: https://forum.openwrt.org/viewtopic.php?id=56521 …
> 
>> 
>>>> The current list is a confusing mix of information about very old,
>>>> sometimes EOL (end-of-life) equipment.
>>> 
>>> What is bad about keeping information? Just because a device is EOL 
>>> by its manufacturer/vendor does not necessarily mean it is completely
>>> out of the retail channel/ second hand retail/sharing channel, so
>>> keeping information how to give such devices a “second life” as
>>> openwrt routers seems like a good idea to me.
>> 
>> Nothing is wrong with keeping the info; the issue is whether and when to
>> push it to a separate page.
> 
> 	Never? Just make the whole thing filterable, which I believe is being prototyped as we speak ;)
> 
>> 
>> Again, I do hope the feedback is useful.
> 
> 	I have a hunch it would be even more useful if voiced in a way the openwrt developers/documenters community could actually see your ideas… (as far as I know Rich Brown is the only one here working on improving the openwrt wiki (and I am really glad he is doing it as I like his documentation a lot, but I digress))
> 
> Best Regards
> 	Sebastian
> 
>> 
>> Joe
> 

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

[Mikael Abrahamsson]

On Mon, 6 Jul 2015, Joe Touch wrote:

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

Yes, that's the one for the WRT1200AC. It's called "caiman" internally at 
Linksys it seems.

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

You can flash back the factory firmware without serial, you just use 
sysupgrade with the Linksys factory image. I've done this. It's not easy 
to get into the box, and I have plastic dents on my unit now because I 
failed to understand how it fits together. I also ended up buying pin 
headers with tweezers to connect the TTL-USB serial device to the 
connector on the PCB. I have since then received proper cables so now I 
have wires sticking out and I'm waiting for connectors so I can make a 
more permanent solution.

I have also had to use the serial console on mine because something broke 
in the upgrade process one of the 30-40 times I did sysupgrade.

I won't speak of the "declared victory". In my opinion the victory might 
be "there is now knowledge on how to do this and there is substantial 
awareness in the rest of the industry" but it's definitely not executed 
yet.

And yes, you're right, there is very little "mainstream" about OpenWrt. 
It's reasonably easy with a lot of devices (and there are guides to read), 
but it's not like anyone can do it. It's like changing oil in a car, it's 
not that hard, but if you don't know how to do it, you need to study first 
and find correct tools in order to do it. Also, if you get it wrong you 
might damage things.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

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

[Mikael Abrahamsson]

On Tue, 7 Jul 2015, Joe Touch wrote:

> Some questions:
>
> On 7/6/2015 11:16 PM, Mikael Abrahamsson wrote:
> ...
>> You can flash back the factory firmware without serial, you just use
>> sysupgrade with the Linksys factory image.
>
> How does that differ from mtd, e.g., as indicated here (which doesn't
> mention sysinstall)?:
> http://wiki.openwrt.org/doc/howto/generic.uninstall

http://wiki.openwrt.org/toh/linksys/wrt1200ac#how_to_flash_the_firmware_to_device

"Revert to Linksys Stock Firmware"

So you can either use the web ui or the "sysupgrade" command to go back to 
Stock firmware.

I have only used the mtd method once, and that was when there was a 
problem with the flash for some reason and I was recommended that method 
instead by an OpenWrt developer.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

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

[Mikael Abrahamsson]

On Fri, 10 Jul 2015, Joe Touch wrote:

> Can you explain where the info on using the sysupgrade command to revert 
> to the factory image is??

http://wiki.openwrt.org/toh/linksys/wrt1200ac#how_to_flash_the_firmware_to_device

The web ui uses the "sysupgrade" command. So implicitly the instructions 
above to use "web ui" to upgrade, means you can use sysupgrade.

http://wiki.openwrt.org/doc/howto/generic.sysupgrade

So I just did:

cd /tmp
wget <url to Linksys factory image I wanted to install>
sysupgrade <filename>

Then it rebooted. I then had to use the factory default button on the 
device to reset the configuration before things started working properly. 
"sysupgrade -n <filename>" does this as well, but I am not sure the 
Linksys configuration data is stored in the same place so that might or 
might not help.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se

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

[Sebastian Moeller]

Hi Joe,


On Jul 10, 2015, at 09:22 , Joe Touch <touch@isi.edu> wrote:

> 
> 
>> On Jul 10, 2015, at 12:03 AM, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
>> 
>>> On Tue, 7 Jul 2015, Joe Touch wrote:
>>> 
>>> Some questions:
>>> 
>>>> On 7/6/2015 11:16 PM, Mikael Abrahamsson wrote:
>>>> ...
>>>> You can flash back the factory firmware without serial, you just use
>>>> sysupgrade with the Linksys factory image.
>>> 
>>> How does that differ from mtd, e.g., as indicated here (which doesn't
>>> mention sysinstall)?:
>>> http://wiki.openwrt.org/doc/howto/generic.uninstall
>> 
>> http://wiki.openwrt.org/toh/linksys/wrt1200ac#how_to_flash_the_firmware_to_device
>> 
>> "Revert to Linksys Stock Firmware"
>> 
>> So you can either use the web ui or the "sysupgrade" command to go back to Stock firmware.
> 
> I see the word "sysupgrade" only her, but that is in reference to the img type not the command :
> 
> ----
> When flashing from OpenWrt, use the "sysupgrade" image. Although the factory image will work, the sysupgrade image has the fringe benefit of preserving the UBI container between flashes, which provides some wear-leveling.
> ----
> 
> Can you explain where the info on using the sysupgrade command to revert to the factory image is??

	Have a look at:
1) http://wiki.openwrt.org/doc/howto/generic.sysupgrade
and 
2) http://wiki.openwrt.org/doc/techref/sysupgrade
this should cover all your bases…

I would assume the following to work from your routers command line interface (so log in via ssh first):
On your client computer:
scp Stock_firmware_image root@your.router.name.or.ip-address:/tmp/firmware.bin
ssh root@your.router.name.or.ip-address
On your router:
cd /tmp
/sbin/sysupgrade -d 60 -v -n ./firmware.bin

(the -d will delay the reboot for 60 seconds giving you time to read the output, the -v will increase the verbosity to help debugging in case of failure, and the -n will not attempt to conserve your setting through the sysupgrade, which will not work for a revert to the link sys image anyway).

Best Regards
	Sebastian


> 
>> 
>> I have only used the mtd method once, and that was when there was a problem with the flash for some reason and I was recommended that method instead by an OpenWrt developer.
>> 
>> -- 
>> Mikael Abrahamsson    email: swmike@swm.pp.se
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

[Dave Taht]

GWB declared victory too early also, so...

0) ubnt's edgerouter series from the X (49 dollars) to the pro - (8
ports, 300 dollars) also has made an investment in making fq_codel and
smart queuing easy to use over their last 3 generations of firmware.
Vers

They are debian based (and closely related to Vyos (formerly vyatta),
which also has gained fq_codel support)

1) At the time development ceased directly on cerowrt, all the major
home router vendors were planning to release for the christmas season,
devices with vastly upgraded shaping and queue management, QoS
features - so life was looking promising. And we worked on refining
edge cases and moving code upstream into other places in addition to
openwrt.

All those vendors goofed in some way or another, but did feature
"Traffic shaping with X" prominently on the box, where X was
Streamboost, Dynamic QoS or some other new marketing catchphrase, with
a lovely gui - netgear's X4 gui was particularly promising... and
their implementation the best of what I benchmarked - but the X4 was
very flaky wifi-wise... and every vendor had no way to turn off nat.
Buffalo may have got it more right but I never got around to test it
(they use dd-wrt).

all of them missed the need for framing compensation on dsl and ppoe
technologies. I realize that getting these right is a human factors
nightmare, but you have to get them right.

Also from a human factors perspective, people seemed to think people
wanted pinpoint control of bandwidth for everything, and developed
guis and tools and invasive means (like streamboost doing dpi) to do
so.

d-link shipped a version of streamboost lacking codel entirely.
Another version of their product did good downstream prio but lousy
upstream, and fq_codel + sqm-scripts smoked it:

http://forums.dlink.com/index.php?topic=61634.0;nowap

I tore apart (as publicly as possible!) the flaws in each vendor's
implementation earlier this year, and asus, at least, has responded
with newer firmware. Most vendors are plagued with 5+ year old
kernels, still, and it is only the ones that were on 3.4 or later that
could respond.

And, we, here, missed the fact that all these new high end home
routers used TSO/GSO and especially GRO, heavily, and we had not
compensated for that.

Cake is a great candidate for the edgerouters and the new higher end gear.

Aside from that, on the low end mikrotik has made some encouraging noises.

So I do have hope that THIS christmas, effective and correct qos and
shaping implementations will begin to arrive across the board.

Also the first pie enabled cablemodems should start appearing late
this summer for test, and I have a bit of hope for seeing an
integrated cablemodem/wifi device from some vendor of showing up also.


On Mon, Jul 6, 2015 at 6:02 PM, Joe Touch <touch@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
>
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast