5 ms·

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 slapp

by blfr 12y ago

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/ https://code.google.com/p/namebench/

higherpurpose 12y ago
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.
- rando289 12y ago
  Specifically, GPLv3 or AGPLv3 to avoid consumer device lock down.
wtallis 12y ago
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.
- dfc 12y ago
  > 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.
  - wtallis 12y ago
    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.
    - dfc 12y ago
      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?
      - wtallis 12y ago
        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.
    - wglb 12y ago
      Might I suggest that you try it out before making such a firm statement?
zippergz 12y ago
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.
- ghshephard 12y ago
  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.
  - fho 12y ago
    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.
windlep 12y ago
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. :(
- nilbot 12y ago
  I believe the DNS compression pointer mutation will both lower your latency and help you identify which DNS is best for you.

by blfr 12y ago

higherpurpose 12y ago

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.

rando289 12y ago
Specifically, GPLv3 or AGPLv3 to avoid consumer device lock down.

wtallis 12y ago

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.

dfc 12y ago
> 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.
- wtallis 12y ago
  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.
  - dfc 12y ago
    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?
    - wtallis 12y ago
      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.
  - wglb 12y ago
    Might I suggest that you try it out before making such a firm statement?

zippergz 12y ago

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.

ghshephard 12y ago
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.
- fho 12y ago
  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.

windlep 12y ago

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

nilbot 12y ago
I believe the DNS compression pointer mutation will both lower your latency and help you identify which DNS is best for you.