Hacker News Reader

Comment by blfr | Hacker News Reader

That's a very ambitious take on this problem. It is pretty cool (and definitely more secure) to run OpenBSD but you can probably get most of the upside by slapping OpenWRT on the consumer router you already have. A $50 WDR3600 happily handles several VPNs, custom VLANs, an IPv6 tunnel, exotic routing, an external drive, and a Samba server while doing the typical SOHO router-y stuff, like wifi.

BTW Running my own name server has solved a lot of weird slowdowns I used to experience when browsing the web or sshing. According to namebench[1], my router doesn't even crack the top three when it comes to response time so I used to have it forward queries but in practice, after it warms up, it's more reliable and delivers a smoother experience than either my ISP or Google.

[1] https://code.google.com/p/namebench/

View on HN

Maybe it's gotten better in recent years, but last time I tried consumer hardware (Linksys), there were actual hardware problems like overheating that didn't get any better with alternative firmware. My Linksys routers (I went through three of them before giving up) would lock up with increasing frequency as they aged, under both Tomato and DDWRT. When I went to Cisco (real Cisco, not Linksys Cisco) and Ubiquiti routers, the problems went away. For the price of a Ubiquiti router (under $100), I personally find no reason to spend time with open source firmware on crappy consumer hardware. It just works and is rock solid.

It can be both, but certainly one issue is hardware quality. The Linksys WRT54G and WRT54GL (of which I've purchased 8), are cheap electronic devices that last on average 12-18 months. I did have one make it out to 3 years, but I also had one kick the can about 6 months in - so it averages out. What's worse, is the failure case is "Intermittent performance" prior to just dying.

Cisco also has made crappy hardware in the past, I've had stacks of Cisco 2960 switches with dead ports, but they make up for it on the business side by having really good RMA processes if you have support agreements. They also make phenomenal hardware as well - I had a Cisco 7206 keep running without any human involvement whatsoever for 10+ years.

I'd be willing to pay $500-$550 for a solid 4 Port GE, 1U Rack Mountable, fully open, appliance that I could drop whatever operating system (OpenBSD preferred), that had gone through some extensive HALT (Highly Accelerated Life Testing) at temperatures -55C to +85C that suggested an average of 20 year life in typical consumer (23C) environments. I bet there are 10s of thousands of people who likewise would jump at the opportunity.

Sometime I wonder why the WRT54GL still get's hyped so much. Yes, it is probably the router that started the whole Wrt projects. But seeing that this 2002 relict still sells for 50+€ (on amazon) pains me. For the same money you get a superior device (eg a tp-link tl-wr1043nd and even that one is quite old by now) that runs Wrt just fine.

Probably for the same reason we buy these: http://www.amazon.com/USRobotics-USR5686G-Serial-Controller-...

They basically get a (minimal) job done. (Though, unlike the WRT54GL, the USR Robotics modems are pretty reliable).

What I don't understand, is why nobody ever built a somewhat robust version of the WRT54GL?

Just build a robust device with a Skyworks 802.11a,b,g,n,ac FEM and maybe four GigE ports. Something plain, vanilla, that you can stick on your desk for 10 years. I bet they'd sell millions of them.

> a superior device (eg a tp-link

My experience with TP-Link has not been that great. I have three TP-Link devices (wireless router, Gig-E switch, and wireless AP) and I've had stability issues with all three since I got them. I regularly have to reboot each device, as each one will inevitably lock up after being powered on for a few days. I've also tried open-source firmware on the router, and it ran terribly no matter which flavor I tried; my 25Mbps WAN connection was reduced to about 5Mbps across the board. It runs at the correct speed with the stock firmware.

I'm seriously considering a build like the one in the article, however I'll probably go with a dual NIC Atom based nano-ITX board instead. Not only will it be cheaper, it will be easy to repurpose as a full fledged PC if I upgrade routers again in the future. A good example is this complete machine for $250, case and all: http://www.amazon.com/dp/B008KB5YCK

We're already seeing some large router makers (slowly) adopt OpenWRT/DD-WRT. Maybe there's a chance we can push for a status quo on using open source firmware for routers - perhaps some sort of "Android" for routers, but it needs to be fully GPL so OEMs can't lock down 95% of it like they do with Android.

Specifically, GPLv3 or AGPLv3 to avoid consumer device lock down.

With regards to the name-server bit, I honestly can't re-iterate this enough. It's amazing how many "My internet is slow" remarks really come down to DNS resolving slowly. My router has WAN failover, and I've had to manually tweak the DNS it chooses many times because even when a WAN is 'up', the DNS it uses might have latency exceeding 2+seconds for hours at a time (Comcast) even though the link itself is perfectly fast (125Mbit).

Merely setting a different DNS source immediately shows off the full potential of the link. I still need to setup my own local DNS server so that I can be rid of this problem entirely. :(

A typical $50 consumer router running OpenWRT will do everything you want except traffic shaping. The cheap consumer stuff all uses slow single-core MIPS CPUs that can only do traffic shaping at tens of megabits and consequently cannot do QoS for a fast DOCSIS or fiber connection. Of course, even if you do go to the trouble of getting an Intel-powered router, you still wouldn't use OpenBSD (or anything other than Linux) for QoS.

  > you still wouldn't use OpenBSD (or anything other 
  > than Linux) for QoS.

Is this still the case? Especially in regards to OpenBSD managing a fast residential cable connection? I thought 5.6 yanked out the slow ALTQ code and brought OBSD close to linux QoS performance, especially for residential traffic management.

From a quick skim of the manpages and a few google searches, it looks like pf is a really poor substitute for tc. Without CoDel and friends, OpenBSD can at best implement half of a good QoS system.

Your categorical rejection of openbsd+pf is based on a cursory google search and man page comparison? I have not seen any QoS comparisons of OpenBSD 5.6 versus Linux. Did you find any?

There's nothing to compare. OpenBSD just plain doesn't have any active queue management. They used to have RED in the altq module, but it's been removed and I haven't found any mention of any other form of support for any of the common AQM algorithms. If it supports anything more advanced than classifying packets into a fixed set of priority queues with fixed packet count limits, it's well-hidden. What functionality is exposed and advertised through their man pages is simply not enough to put together a fully functional QoS system, regardless of how efficient it is with CPU time. There isn't even the theoretical possibility of OpenBSD doing good QoS unless they've got a large amount of complexity hidden and misleadingly glossed over by their documentation. In this case, running a dumb algorithm arbitrarily fast can never compete with the smarter algorithms.

Might I suggest that you try it out before making such a firm statement?

Try what? The pf.conf man page section for queuing describes only functionality that is effectively equivalent to HTB or possibly HFSC on Linux. That algorithm on its own fundamentally cannot keep latency low because it has no mechanism to restrict queue length without crippling bandwidth. If OpenBSD's current HTB-equivalent is much more efficient than it used to be, that's an improvement but it's still only one of several required components and cannot get the job done on its own.

I second that motion. Try it (OpenBSD with pf). I have not played with traffic shaping for myself but as always with OpenBSD I guess i would be surprised how well it works. set prio, set queue and set tos seems to be the "tools" to use.

Why should I expect OpenBSD to not suffer from the universal problems of overly large queues when they haven't documented any mitigation techniques? I can't even find out how to get OpenBSD to do ECN marking without the now-removed altq module.

Does this help https://calomel.org/pf_config.html?

Why not?

i'm too lazy to search, but almost every cheap modem OS and even windows and OSX were susceptible to pings or some other connection completely blocking out all honest traffic.

Reply on news.ycombinator.com