Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Home Routers w/ Decent QoS Performance?

Cliff posted more than 9 years ago | from the from-the-office-to-the-mainstream dept.

The Internet 52

danwarne asks: "With VoIP becoming rapidly more popular, quality of service (QoS) settings in home routers are also emerging as a key piece of functionality for the average user. QoS settings, which allows important or time-sensitive network traffic to be prioritized over less important packets, used to only be offered for corporate-level routers. Now, many hardware manufacturers have started including such capabilities in their mainstream routers, some doing it simply by a firmware upgrade without any change to the power of the underlying hardware. The emerging problem is that most home routers don't do a very good job at all with QoS, especially under heavy load (from P2P apps, for example), and home routers don't seem to have what it takes to prioritize sending Voice over IP packets first, leading to glitchy VoIP calls. VoIP operators around the world are facing this problem as they try to turn VoIP into a 'consumer-friendly' plug-and-play service. Does anyone know if someone has done extensive testing on home routers and modem/routers that investigates their ability to deliver QoS? Also, what hardware elements would be required in a router to do QoS reliably?"

cancel ×

52 comments

Sorry! There are no comments related to the filter you selected.

Easiest answer: (4, Informative)

mikeage (119105) | more than 9 years ago | (#11793659)

WRT-54G(S) running sveasoft's firmware. Yes, some people question the legality of the distribution method, but at $60 for the router + $20 for the firmware subscription, it's an instant solution. I'm running it on a 1.5Mbps/96Kbps to manage bittorrent, emule, packet8, counter-strike, and websurfing, and it runs great. More important -- it passes the wife test (aka, she doesn't notice that I'm downloading while she's talking).

Re:Easiest answer: (5, Informative)

aderusha (32235) | more than 9 years ago | (#11793790)

to save yourself the $20 (and the general assholery that sveasoft is prone to), download the GPL'd firmware here: http://www.gonzo-wireless.co.uk/torrents/

if you're wondering what all the stink is about, read here: http://wrt54g.serwer.net/

Re:Easiest answer: (4, Informative)

Anonymous Coward | more than 9 years ago | (#11794070)

For a more hassle-proof source of information, go to http://slashdot.org/~TheIndividual/journal [slashdot.org]

Re:Easiest answer: (4, Informative)

alatesystems (51331) | more than 9 years ago | (#11794453)

Just get it from TheIndividual [slashdot.org] here on his slashdot journal. An AC posted this below, but he's at 0 and I don't have mod points, so I'm reposting it.

I've used the Sveasoft firmware in the past, but I immediately returned the router. That WRT54g is just not fast enough to deal with my 8mbps internet and do QoS on it at the same time. I went back to using my custom iptables and QoS scripts on my linux box which is an athlon xp 2000+.

That Sveasoft dude is an evil idiot, and needs to be hit on the head with a GPL stick. I wouldn't pay him for it, even if he included the antidote.

Not surprised (1)

Andy Dodd (701) | more than 9 years ago | (#11794582)

The WRT54G also has serious thermal problems when the CPU operates at heavy load.

A friend of mine bought one, it would crash every 10-15 minutes if you were running WEP with light-moderate WLAN use.

30 minutes or so if WEP were off.

2-3 hours even at moderate-heavy loads if you were only using the wired ports.

Best bet might be some sort of Mini-ITX box.

Re:Not surprised (1)

rthille (8526) | more than 9 years ago | (#11795048)

How can you be certain it was thermal? I wouldn't be surprised if it were memory corruption or leaks (especially if they were running the stock firmware). Did you try the tests with a fan blowing cold air over the top of the unit?
(I'm actually interested in the results, since I've got a WRT54G I've been meaning to put OpenWRT on for QoS and to use as a firewall/DMZ/public wireless box.

Re:Not surprised (2, Insightful)

bill_mcgonigle (4333) | more than 9 years ago | (#11796856)

The WRT54G also has serious thermal problems when the CPU operates at heavy load.

A friend of mine bought one...


And if that anecdote were typical a huge community wouldn't have grown up around the unit and Linksys would be buried by the support nightmares.

It could be that your friend got a bad unit -OR- maybe hundreds of thousands of people don't realize that their units are crashing all the time. We'll let Occam's Razor decide that one.

Re:Not surprised (1)

leuk_he (194174) | more than 9 years ago | (#11811404)

That is the exact same reasoning people used for windows-95. Such an intensively tested product could not contain any errors. Could it? Suprisenly several people here mention it. Could they all be wrong?

Re:Not surprised (1)

bill_mcgonigle (4333) | more than 9 years ago | (#11812559)

That is the exact same reasoning people used for windows-95. Such an intensively tested product could not contain any errors. Could it? Suprisenly several people here mention it. Could they all be wrong?

I'm sorry, I didn't notice that a huge community of avid networking hackers and unix gurus had grown up around Windows 95. I didn't even know you could customize your build of Windows 95. I must have been asleep.

Re:Not surprised (1)

stungod (137601) | more than 9 years ago | (#11807324)

It's funny you mention this. I have been having the same problem with mine and finally traced it to temperature.

I have been running the Sveasoft firmware and thought that it was the problem at first. However, after reverting back to the stock FW I got the same problems without any of the benefits.

For a long itme I thought it was my Xbox causing problems with the network. I only really got steady trouble when I had the Xbox turned on. It took longer than it should have for me to correlate how hot the AV closet got when the Xbox was turned on to the Linksys problems.

So now I'm going to install a vent fan in the closet to keep things cool. As for the WRT54g, I may take the top of the case off so air can move more freely over the hot bits. If anybody else has had/solved the heat issue with these routers, I would love to know more.

Re:Easiest answer: (1)

Money for Nothin' (754763) | more than 9 years ago | (#11804432)

Wow. I don't own a WRT54G, so I'm not involved in that circle of users/devs, but after reading about some of the things James has done, man, he's total asshole. I would NEVER buy his firmware.

Banning people from the forums who've paid $20 and happen to be using the same nick on another forum? Sending people nastygrams for discussing the source? Fuck James.

I've never heard of a purportedly "open-source" developer acting like such a dickweed before...

Re:Easiest answer: (3, Informative)

adolf (21054) | more than 9 years ago | (#11796156)

For anyone looking to buy a WRT54G:

Try to avoid version 2.2 of this router if you're at all interested in more advanced networking stuff (VLAN, per-port QoS, etc).

Versions 2.2 use an Atmel ethernet bridge chip which supports all sorts of management tricks, many of which are supported in the Sveasoft firmware. This makes some things very easy - you can run an ethernet drop your neighbor's house and give them their own VLAN to keep them out of your network, for example. Or plug your VoIP terminal into its own port, and give that physical port QoS priority over everything else.

It's almost like having a Linux box with five independant ethernet interfaces, plus 802.11g, for $60 (!).

Version 2.2, which is the latest at this time, is essentially the same unit except that it contains a cheap unmanaged Broadcom ethernet bridge. Which works fine, except that your potentially lovely 5-port networking monster just turned into a 2-port model with a built-in dumb 10/100 switch. Which means that you'll need at least two of 'em (or a whole different plan) to split the cable bill with your neighbors, no more per-port QoS, and such.

Otherwise, they'll all run the same firmwares, and are feature- (and cost) identical.

FYI.

Re:Easiest answer: (1)

Jacco de Leeuw (4646) | more than 9 years ago | (#11803508)

Versions 2.2 use an Atmel ethernet bridge chip
Version 2.2 contains a cheap unmanaged Broadcom ethernet bridge

I assume you mean "versions prior to 2.2" in the first sentence?

Re:Easiest answer: (1)

adolf (21054) | more than 9 years ago | (#11810273)

Yes. Yes, I did.

Slashdot ate my less-than symbol.

To summarize:

v2.0 and prior versions of the WRT54G are excellent.

v2.2 is also excellent, though less featureful.

And, to be complete:

The WRT54GS v1.0 is excellent, and has twice as much ram as a v2.x WRT54G, along with VLAN abilities.

The WRT54GS v1.1 is also excellent, and also sports extra RAM, but suffers from the same limited Broadcom bridge chip as the v2.2 WRT54G.

Re:Easiest answer: (1)

kcb93x (562075) | more than 9 years ago | (#11830356)

I'm quite certain mine's a 1.0, or a 1.1...cool. I'm still running the stock software loadout, and it's worked fine for me when I've needed to use it.

Anyplace to find out more on what the different revisions have/don't have etc?

lol (-1, Offtopic)

Anonymous Coward | more than 9 years ago | (#11793686)

that's the 5th Ask Slashdot on the frontpage! About the topic: Get an old unused PC, put OpenBSD on it and read over the pf FAQs. Very cute indeed!

Commercial Products are Inadequate (1)

aelbric (145391) | more than 9 years ago | (#11793799)

Well, I am no expert but I can tell you my experience so far has been less than stellar. Products by Linksys, D-Link, and Motorola have QoS options that work reliably. That is only is you have no expectation of performance as far as gaming, P2P, or even web surfing is concerned while you are using your VOIP. The problem is that the number of connections that they allow (for security reasons) is far too low to allow any real use and the settings are hardcoded. As soon as you hit that limit (whatever it is), performance goes right in the crapper.

I built a RedHat box running dual NICs and firestarter that works amazingly well. Still working out QoS on Linux though. As long as I don't hit 70% utilization up or down, I have had no problems.

Re:Commercial Products are Inadequate (3, Insightful)

walt-sjc (145127) | more than 9 years ago | (#11794173)

If you are on ADSL, you can greatly improve QOS by getting a sangoma DSL card instead of using the telco supplied DSL modem. The problem with traditional DSL (and cable) modems is the huge input buffer. The way people get around this buffer is to limit the upstream speed to less than full wire speed so that the buffer is always empty.

QOS is most freqently needed on upstream data since downstream has higher speeds. Since most ISP's don't support QOS at all, about the only place you have any control is upstream on the local loop.

Linksys WRT54GS w/ Sveasoft (4, Informative)

maggard (5579) | more than 9 years ago | (#11793811)

I reccomend the Linksys WRT54GS. It's about US$10 more then the G model but includes more memory you'll be able to take advantage of in the future. The router can be found online for around US$60 online or US$90 retail.

Then install the Sveasoft firmware. The shipping version is free, access to the beta version & support for it is US$20. Some folks dissaprove of this strategy but the FSF has green-lighted it and it does pay for the project.

QoS, VPN (endpoints), SSH, filtering, upped antennae power, it's all there. They've extended the Linksys web interface to handle most of the expanded functioniality and below that there's a real working Open Source Linux with a happy command line.

Sure it's not an old clunker running something else. It's also small, quiet, stable, wireless if you want to take advantage of that. I dunno about you but being able to replace a 24/7 big noisy hot box in my living space with a smaller quieter cooler one is worth the small premium.

Re:Linksys WRT54GS w/ Sveasoft (5, Informative)

Anonymous Coward | more than 9 years ago | (#11794091)

Actually the development version is free as well, because it's licensed under the GPL. You can pay $20 for support, if you want, but if you don't need support you can also get the firmware here [slashdot.org] .

Re:Linksys WRT54GS w/ Sveasoft (2, Interesting)

vlm (69642) | more than 9 years ago | (#11795920)

Take advantage of the larger memory in the future?
You can take advantage of it today for free if you use the openwrt.org distribution instead of Sveasoft

I use the openwrt, the S provides quite a bit more space for stuff.

Optimizing ADSL (4, Interesting)

ion++ (134665) | more than 9 years ago | (#11793824)

A friend of mine wrote his master thesis about optimizing the usage of asyncrone internet connections (often ADSL connections). He used our dorm as a living experiement, we have 307 people living here, and share one 8196 kbit down / 768 kbit up ADSL connection. All our ports are open and everyone has a puplic ip address (well almost, because we only have a /24).

The results are very very good. The link is actually useable now. SSH connections are quick. people can and does use p2p without trouble. VoIP works most time of the day, but during "rush" hour it is not possible, most likely because we are just too many users for such a small connection. Games might also work at some time during the day, but i dont game so i wouldnt know. I do hear that some people complain that they can not game. The rest is good, SSH, HTML, news, irc/IM and other chats works as well. Try it, and you dont even have to limit your bandwidth.

http://www.adsl-optimizer.dk/ [adsl-optimizer.dk] contains his master thesis.

QoS to where? (3, Informative)

iksowrak (208577) | more than 9 years ago | (#11793849)

Are you trying to control QoS between two endpoints over the public Internet? If so, tagging the voice traffic leaving your router isn't going to do much good since once you hit the rest of the Internet the other routers on the trip to your destination will immediately disregard any QoS settings that your router has set. Otherwise we'd have boneheads sitting at home configuring their routers to send all their gaming or P2P download traffic with voice level priority. You currently can't control QoS over the public Internet.

Re:QoS to where? (3, Informative)

Anonymous Coward | more than 9 years ago | (#11794264)

The issue is more with the last mile than with the public internet. The backbones are usually not under high stress, but it's easy to saturate a DSL connection. QoS in that context means you try to minimize latency and reserve bandwidth for certain protocols by throttling protocols without realtime requirements. That is possible to a certain extent, but upstream bandwidth usually puts a severe limit on latency: Let's say you can send at 128kbit/s. That's 60ms per KByte, or about 100ms per max-size packet.

Now suppose you prioritize VoIP traffic (small packets, low bandwidth usage but low latency is important) over file transfers (large packets, high bandwidth usage but no latency requirements) and an upload packet arrives at your router. The bandwidth quota for file transfers is not used up right now and there's no VoIP packet waiting, so the router starts sending the 1500 byte TCP packet. In the meantime a VoIP packet arrives at the router, but even though it has priority over file transfers, it has to wait until the packet which is currently being sent is finished. That adds on average 50ms to your VoIP latency (100ms max). The only difference QoS makes here is that VoIP packets can cut into line when other file transfer packets are waiting to be sent.

(Mod parent up) (0)

Anonymous Coward | more than 9 years ago | (#11794990)

Now I understand why QoS works so poorly on my router.

Re:QoS to where? (1)

skybrian (8681) | more than 9 years ago | (#11795941)

Couldn't you reduce the MTU (maximum TCP packet size) for outgoing packets? If the problem is as you say, that should help a lot.

Re:QoS to where? (1, Informative)

Anonymous Coward | more than 9 years ago | (#11796791)

Reducing the MTU helps with the latency but increases overhead (processor load and bandwidth for more headers).

Re:QoS to where? (1)

djweis (4792) | more than 9 years ago | (#11798964)

Lowering the MTU is one option but causes problems in the general case of http/ftp transfers. Many T1 routers can do frame relay or PPP fragmentation to let the smaller voip packets through. It is also supported on atm/dsl.

Re:QoS to where? (1)

afidel (530433) | more than 9 years ago | (#11802364)

That's why the atrocious upload most US connections are saddled with is so nausiating. I have 300Kbps upload and I think that's the bare minimum for something to be called broadband. This gives 30ms latency for large packets, or an extra 15ms average for VoIP traffic, generally acceptable. It also allows enough response traffic to keep the pipe full at 3Mbps down even with chattier protocols. I would love to have 768+Kbps but my cable ISP doesn't offer it even on the "delux" level package which costs twice as much per month.

Re:QoS to where? (0)

Anonymous Coward | more than 9 years ago | (#11808458)

Actually the maximum delay is the relevant figure because VoIP needs a steady stream of packets. It has to adjust to the slowest packets, not to the average delay. A QoS optimized 128kBit/s DSL connection cannot achieve less than 100ms one-way VoIP latency during an upload with 1500 byte packets.

DSL providers could mitigate this effect without increasing the bandwidth by operating the last mile at higher speed and limiting the bandwidth at their end. Then you could effectively avoid running into the bandwidth limit by shaping your outgoing traffic. Latency would become negligible even with large packets almost saturating your bandwidth limit.

Re:QoS to where? (0)

Anonymous Coward | more than 9 years ago | (#11803907)

The other reply was informative, but defective in that it did not inform you that you are an idiot. You are now being so informed, seeing as how this entire discussion is about home users trying not to saturate their feeble cable/dsl upload bandwidth, and here you are babbling about some nonsense like having your home router do QoS for internet backbones. Idiot, and who the heck modded this up.

QoS has to be supported on the other side... (3, Insightful)

wowbagger (69688) | more than 9 years ago | (#11793960)

The big issue with QoS is that your ISP also has to support it, or you don't get the benefit of it.

Consider the case of downloading a big file, and trying to do VOIP. The incoming VOIP packets and the incoming download packets hit your ISPs router.

Now, unless the bandwidth between you and your ISP's router is larger than the bandwidth between your ISP's router and the rest of the world, there will be an outstanding queue of packets to be sent from the router to your computer. If the router does not honor the QoS bits of the incoming packets, and send the VOIP packets first, then your VOIP will be choppy, even though your router is sending all outbound VOIP packets out first.

Moreover, even if your ISP supports QoS, if the machine generating those packets does not set the QoS bits correctly, there will be no way for your ISP's router to assign meaningful priorities - so even though you've tweaked your system to set the QoS on outbound packets correctly, if you are talking to Aunt Tillie, and her computer is not setting the QoS bits, then the incoming traffic will not be sorted correctly.

Re:QoS has to be supported on the other side... (0)

Anonymous Coward | more than 9 years ago | (#11794152)

An optimum QoS solution requires ISP support, but with rate controlled protocols like TCP you can limit the incoming traffic on your end. The remote computer will adjust to your speed of packet acceptance. Otherwise a computer on a fat pipe would constantly send more packets than you can receive and waste bandwidth on packets which have to be thrown away at some point. If you limit incoming traffic of a certain class to 80% of your real bandwidth, then continuous traffic (like long downloads) will leave the other 20% free for whatever you assign to that slot.

Not necessarily. (4, Interesting)

swillden (191260) | more than 9 years ago | (#11794301)

The big issue with QoS is that your ISP also has to support it, or you don't get the benefit of it.

You don't get the full benefit, but you can still use QoS to shape incoming data streams, at the expense of giving up a portion of your inbound bandwidth.

The way this works is that although your ISP will send whatever packet is at the head of the queue, your router can still reorder the incoming packets before delivering them to your computers. That looks, at first glance, like a silly idea, since the router has the data and there is no bottleneck across your 100Mbit LAN, why shouldn't it just deliver what it gets?

By delaying, or even discarding, inbound packets, your router can use TCP's throttling mechanisms to slow the rate at which the origin server sends data. When the origin server doesn't receive acknoledgement that a packet was recieved, it not only retransmits that packet (after a delay), but it also adjusts the window size. This is a critically-important property of TCP. Without it, every connection that crosses a low-bandwidth link would suffer lots of dropped packets and would have lots delays during which even the slow link is idle. That doesn't happen, because TCP automatically "tunes" every connection to a rate at which the traffic flows smoothly.

When your router drops inbound packets of a download that exceeds the amount of bandwidth the router wants that connection to consume, TCP adjusts the data rate downward until not many packets are dropped.

So, if your router "knows" the total incoming bandwidth, and if it can track all of the incoming data streams, it can dynamically choose a target bandwidth rate for each of those streams, and then enforce that rate by discarding packets whenever the stream exceeds its target rate. Linux QoS capabilities also include "random early detection", which randomly chooses to occasionally discard a packet from a stream that is close to its target bandwidth, to keep it from going over even briefly.

The downside of this QoS is that in order to make it work effectively you have to make sure that the ISP rarely queues packets and hardly ever discards them. To do that, you have to configure your router to divvy up an incoming stream that is slightly smaller than you really have, because this sort of "remote control" of the origin servers' data rates is imperfect and you will get occasional "blips" of over-target incoming data.

Re:Not necessarily. (0)

Anonymous Coward | more than 9 years ago | (#11794324)

Very handy. Thanks.

Re:Not necessarily. (2, Interesting)

rthille (8526) | more than 9 years ago | (#11794757)

Further, your router which is doing QoS can send 'source quench' ICMP packets to slow the incoming traffic. There isn't really a standard for what the receiving host will do with the source quench packet, but I believe in general it's equivalent to dropping the packet (that is, same bandwidth & window size changes) without the extra bandwidth of resending the dropped packets. The company Packeteer was founded to sell boxes which managed bandwidth on a network just by monitoring the traffic and send source-quench packets.

Re:Not necessarily. (0)

Anonymous Coward | more than 9 years ago | (#11795163)

ICMP packets are easily forged. Relying on the built-in flow control of TCP is advisable because source quench is often blocked at the other end.

You have no idea what you're talking about (0)

Anonymous Coward | more than 9 years ago | (#11795368)

you can still use QoS to shape incoming data streams

This sentence is so wrong it's not even funny. To paraphrase Linus, "it's so wrong, that even if it were right, it would still be wrong."

First off, you *can't* shape incoming data - you can *police* it, but you can't shape it (because you've already received it.) Shaping refers to altering the traffic flow by delaying packets. You can't delay something you've already received.

Second of all, QoS does not shape or police data at all - it has to do with assigning priority, which the router uses for advanced queuing. Note that you can *use* QoS to shape your data, but not the other way around.

Also, 'reordering' packets has *nothing* to do with shaping or QoS. Reordering has to do with individual TCP streams. What you're talking about is called *queuing* (more specifially prioritized queuing).

Do yourself a favour and go get a *real* book on this stuff, you'll look like a lot less of a moron.

Re:You have no idea what you're talking about (0)

Anonymous Coward | more than 9 years ago | (#11795728)

What is received will be sent. We're talking about a router, after all. The inbound shaping is done on the router's LAN side, where it sends. The effect of the shaping is that TCP adapts to the perceived bandwidth limit and reduces the flow. That in turn leaves more bandwidth for prioritized protocols, thereby increasing their quality of service.

Reordering on the LAN side makes no sense, because the bandwidth limit is negligible, so there's no perceivable latency improvement. Delaying or discarding packets in the inbound direction does make sense because it causes TCP to adjust the flow of future inbound packets.

Re:You have no idea what you're talking about (3, Insightful)

swillden (191260) | more than 9 years ago | (#11797042)

Yes, I abused the terminology pretty badly, but I notice you didn't correct my explanation. Would it have been clearer if I'd spent an additional paragraph or two defining the words precisely? I doubt it. And I would have had to, because all of the previous conversation was misusing the terminology. Sometimes to communicate effectively you need to go along with minor errors in order to avoid clouding the main point.

As to your specific comments:

First off, you *can't* shape incoming data - you can *police* it, but you can't shape it (because you've already received it.)

But you can shape the future packet stream by dropping or delaying packets and provoking a reaction from the origin server. You could argue that you're not shaping the traffic so much as convincing the origin server to shape it, but what's the point in drawing that distinction?

Shaping refers to altering the traffic flow by delaying packets. You can't delay something you've already received.

That's a rather funny comment. If your job (as a router) is to pass packets along, of *course* you can delay something you've already received. It's usually simpler and nearly as effective (for TCP) to simply drop it, but you could certainly put it on a queue to be delivered a bit later.

Second of all, QoS does not shape or police data at all - it has to do with assigning priority, which the router uses for advanced queuing. Note that you can *use* QoS to shape your data, but not the other way around.

LOL. The sentence fragment you're disputing is: "you can still use QoS to shape incoming data streams." You contracticted that with: "you can *use* QoS to shape your data". I'm not pointing that out to imply that you're saying I was right but to point out that that *is* a useful way of describing the situation, even if it's not perfectly accurate.

Yes, I understand that QoS is really about prioritization of traffic, but unless you are actually trying to describe the distinct phases of processing in a sophisticated router, splitting this hair serves no purpose.

Also, 'reordering' packets has *nothing* to do with shaping or QoS. Reordering has to do with individual TCP streams.

That's one usage of the word. It also applies in other networking contexts.

Do yourself a favour and go get a *real* book on this stuff, you'll look like a lot less of a moron.

Try reading more than a single book on this stuff and you'll find that the terminology isn't as hard and fast as your narrow experience has led you to believe. Further, spend some time trying to explain complex subjects to non-specialists and you'll discover that perfect accuracy in terminology is not at all the same as effective communication.

Re:You have no idea what you're talking about (0)

Anonymous Coward | more than 9 years ago | (#11826321)

Well said!

Bandwidth (2, Insightful)

JeffTL (667728) | more than 9 years ago | (#11793964)

If you don't have oodles of bandwiddth and want to be able to talk and play network games at the same time, maybe you should stick with a telephone solution not using the public Internet, such as an RBOC land line or digital service from the cable company. Not as cheap as Vonage, I will admit, but if you have to buy more bandwidth from the ISP to do everything you did before, why change?

offtpc - run bsd server as firewall (pf settings!) (5, Insightful)

QuietRiot (16908) | more than 9 years ago | (#11794021)

/// From Slashdot : Which BSD for an Experienced Linux User? [slashdot.org] :: (Score 5, Informative) [slashdot.org] ///

...
OpenBSD would be great to learn on as it will definately push you into the documentation and get you used to some of the conventions used (slices v. partitions, startup scripts, etc.). I'd suggest you use an older or spare computer if you've got extra or can pick one up cheap. You could also just set aside space on those 80 gigs you've got. READ UP ON PARTITIONING, USE OF LARGE DRIVES, ETC. BEFORE YOU START ANYTHING!

Once you get some OpenBSD under your belt, put a box in service at your network connection (right behind you cable/DSL connection?) and
learn to setup pf (packet filter - built in). Experiment with AltQ and get yourself a good firewall/NAT in place (junk the Linksys). Not too much trouble and the docs at OpenBSD - pf [openbsd.org] [openbsd.org] are quite good. Here you could experiment with adding a web server or MTA (if you don't have tons of boxen to keep your "real" services in some kind of dedicated DMZ). My home OpenBSD box forwards BitTorrent, Freenet, VNC and SSH to a variety of machines in my house. I also prioitize packets in the following order: 1st to tcp_ack_out, [then] Vonage telephone, ssh_interactive, everything else, freenet, and finally ssh_bulk. Keeps my phone line crisp and prevents freenet from destroying my ssh sessions' latency. You can do this with other products but I've had a good time (and have learned quite a bit) constructing my /etc/pf.conf file. (Yes. I've got a life otherwise :)

Then build youself a FreeBSD box. This should be cake. 5.x should install without a problem for you and you've got access to all the ports you could ever imagine. Your experience with OpenBSD will help you understand some of the differences you'll encounter. Makes a great desktop. OpenBSD will work fine as a desktop machine but I've never done it. Same for NetBSD I suppose. Give it a whirl. I'm sure you'll learn a ton and be quite happy with whatever you decide.

Don't short yourself on learning OpenBSD. It is awesome, security aware and has some wonderful features (need encrypted swap case the feds might knock down your door at any minute? check.). It may just serve all your needs and knowing it is surely going to be useful to either yourself or others in the future. Use it for utility and the ability to sleep at night with your data behind it. (still better go with RSA keys on sshd though). Check out http://undeadly.org/ [undeadly.org] [undeadly.org]

Don't short yourself either on checking out FreeBSD. I moved from Linux to "the beast" some 5 years ago and haven't looked back since. The 4.10 machine I use everyday has been up 168 days as of today. I had at shutdown the machine previous to that due to a scheduled power outage. It sits fully exposed on an unprotected IP and runs user apps, a web server and mail. Not a single problem in years. FreeBSD has certainly served me (and some clients of mine) well.

If you're a system developer or like playing with things at the driver level or experimenting with new code, new systems or want to put your toaster on the network, don't deny yourself a NetBSD 2.x install. Wonderful features at the leading edge. Very capable and I hope to get some more experience with it myself one day. (a NetBSD page [starling.us] )

Learn OpenBSD. You won't regret it. [FreeBSD and NetBSD will run pf as well]

Here's the juice: (yes - read the docs and modify for your own setup. The various sections need to be in a certain order too (options, normalization, queueing, translation, filtering)
## THIS CODE IS NOT COMPLETE AND MAY NOT BE USEABLE "AS-IS"
## man pf.conf
## ===========

# LAMENESS FILTER ALERT !! # Characters have been skewed and spaces inserted!

# Macros: define common values, so they can be referenced and changed easily.
# Can be defined anywhere in the file
ext_if="xl0" # external interface name
int_if="vr0" # internal interface name
internal_net="192.168.0.0/8"
priv_nets = "{ 127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12, 10.0.0.0/8 }"

# Machines on local net
voip_box="192.168.0.100/32"
dexter="192.168. 0.34/32"
torrent_box="192.168.0.101/32"
freenetm achine1 = "192.168.0.34/32"
freenetmachine2 = "192.168.0.101/32"
VNC_0="192.168.0.103/32"
VNC_ 1="192.168.0.34/32"
SSH_1="192.168.0.34/32"
SSH_ 1_PORT="23"

# ports, other
icmp_types = "echoreq"
tcp_services = "{ 22, 23, 80, 777497, 77713}"
freenetlistenport1 = "777497" ### No copying!!!
freenetlistenport2 = "77713" ### These have been changed. Use your own!
freenetdistribport = "8891"

# Tables: similar to macros, but more flexible for many addresses.
table <localnonVOIP> { $internal_net, !$voip_box }
table <freenet> { $freenetmachine1, $freenetmachine2 }
table <voip> { $voip_box }
table <torrent> { $torrent_box }

# ALTQ stuff
# Let's help Vonage with interactivity and help out downloads when uploading
altq on $ext_if priq bandwidth 100% queue { tcp_ack_out, std_in, std_out, \
ssh_interactive, ssh_bulk, voip_in, voip_out, freenet }
queue tcp_ack_out priority 15 priq (red)
queue voip_out priority 10 priq (red)
queue voip_in priority 9 priq (red)
queue ssh_interactive priority 8 priq (red)
queue std_out priority 5 priq (default red)
queue std_in priority 4 priq (red)
queue freenet priority 2 priq (ecn) #Exp. Cong. Notification
queue ssh_bulk priority 1 priq (red)

# Ahhh. The magic of it all... (pf basically gives you a NAT in one line)
nat on $ext_if from $internal_net to any -> ($ext_if)

# MORE TRANSLATION AND REDIRECTION STUFF HERE
# Connect to dexter's ssh on -p23
pass in on $ext_if inet proto tcp from any to $SSH_1 \
port $SSH_1_PORT flags S/SA keep state queue(ssh_bulk, ssh_interactive)

# SSH in and out should be made useable for interactive
# I care much less about speed on non-interactive ssh use like scp
# for queue, 1st is normal, 2nd is for ACK out & TOS=nodelay
pass in on $ext_if inet proto tcp from any to ($ext_if) \
port ssh queue(ssh_bulk, ssh_interactive)
pass out on $ext_if inet proto tcp from ($ext_if) \
to any port ssh queue(ssh_bulk, ssh_interactive)

# THIS ONE WAS TRICKY
# The rdr above pointing to $freenetmachine1's $freenetlistenport. This was
# causing a 'block' as the rule would not match if set with a
# destination of ($ext_if). The 'new' (translation comes first)
# destination is $freenetmachine1 and thus must be stated as so
pass in on $ext_if inet proto tcp from any to <freenet> \
port $freenetlistenport1 flags S/SA synproxy state queue freenet
pass in on $ext_if inet proto tcp from any to <freenet> \
port $freenetlistenport2 flags S/SA synproxy state queue freenet
pass in on $ext_if inet proto tcp from any to <freenet> \
port $freenetdistribport flags S/SA synproxy state queue freenet

# pass IMCP stuff nicely
pass in on $int_if inet proto icmp all icmp-type $icmp_types keep state

# Make downloads fast by letting the ACKs out
pass out on $ext_if inet proto tcp from $ext_if to any flags \
S/SA keep state queue tcp_ack_out

# Queue regular traffic somewhwhere in the middle
pass out on $ext_if proto tcp from <localnonVOIP> to any \
flags S/SA synproxy state queue std_out
pass out on $ext_if proto { udp, icmp } from <localnonVOIP> to any \
keep state queue std_out

# Make voip super interactive for smooth conversation
pass in on $ext_if proto { udp, icmp } from any to <voip> \
keep state queue voip_in
pass out on $ext_if proto { udp, icmp } from <voip> to any \
keep state queue voip_out

# Freenet traffic
pass out on $ext_if inet proto tcp from <freenet> port \
$freenetlistenport1 to any keep state queue freenet
pass out on $ext_if inet proto tcp from <freenet> port \
$freenetlistenport2 to any keep state queue freenet
pass out on $ext_if inet proto tcp from <freenet> port \
$freenetdistribport to any keep state queue freenet

Re:offtpc - run bsd server as firewall (pf setting (1)

rthille (8526) | more than 9 years ago | (#11795026)

How does pf differentiate between ssh_bulk and ssh_interactive?

Re:offtpc - run bsd server as firewall (pf setting (1, Interesting)

Anonymous Coward | more than 9 years ago | (#11795212)

The sshd program sets the tos bit in outbound traffic. That lets upstream hops determine which port 22 packets are bulk and which are interactive.

Re:offtpc - run bsd server as firewall (pf setting (1)

thinkninja (606538) | more than 9 years ago | (#11805879)

Wow, very cool :)

That's very similar to what I hope to set up with my OpenBSD bridge. Now to profess my ignorance: You're queueing everything on the external interface (flowing to the Internet) but nothing on the internal*? Is that the recommened practice for a small home/office?

* I can see the mistake I made here. With a bridge I should only try and filter on one (the external) interface.

And you other hardware...? (2, Informative)

tyler_larson (558763) | more than 9 years ago | (#11794694)

QoS is simply the prioritization of packets in a particular box's send queue. Either a box can do it or it can't. If your router implements QoS, your router isn't the problem.

Look at your other hardware. If your router can put packets out at 100Mbps, and your cable modem can put out packets at 1.5Mbps, implementing QoS on your router won't get you anywhere--you're router's packet queues are empty. Your cable modem needs to implement QoS too. Cable modems have huge packet queues and can introduce whole seconds of latency--they're usually optimized for throughput only.

You've got, as I see it, three potential solutions:

  • Get a cable modem/DSL modem, etc. that implements QoS queuing.
  • Get a connection that's faster than your router (not the cheapest option)
  • Throttle the traffic on your router so that it only puts out data at such a rate that the cable modem's queues are always empty.

There's more to designing a network archetecture than just buying the hardware. You have to really understand what each element of your network is actually doing.

Re:And you other hardware...? (1)

rthille (8526) | more than 9 years ago | (#11796848)

Sure, your cable/dsl-modem doesn't implement QoS, and it's got asymetric interfaces (DSL/Cable on one side, 100MBit on the other) and so the queues get full, latency goes up and VOIP starts dropping packets because once a VOIP packet is more than a certain amount late you might as well ignore it. The solution to this is to do QoS on your router and limit the connection speed between the router and the DSL/Cable modem to less than or equal to the bandwidth your modem has available. Even on the downstream side, though you can't directly control the packets sent by all the sources you're receiving from, you can indirectly control them by sending source-quench ICMP messages and by delaying sending ACKs on the packets. So, the router implementing QoS has to understand the traffic available on the far side of the modem, but that doesn't mean it's not implementing QoS successfully.

You can't go wrong with Cisco (3, Informative)

jsailor (255868) | more than 9 years ago | (#11797226)

Jump on E-Bay and look for an 806, 831, or 1710.

The 806 is a dual Ethernet router that will do a good job with QoS. It handles Low Latency Queuing for VoIP (essentially priority queuing - whenever it sees a VoIP packet - or any other type you define as high priority - it places it at the head of the output queue. It also supports Committed Access Rate (CAR) for restricting traffic rates for traffic patterns that you define (e.g. by IP address, protocol, mac address, combinations of these). Class-based traffic shaping which smooths the output rate to specified bit rates. CAR polices, shaping controls the actual rate of transmission. It also supports a number of other congestion management features along with a good deal of Cisco's higher end features.

The 831 is similar to the 806, but includes a built-in hardware accelerator for encryption that enables 3DES at rates of 2 Mbps or more.

The 1710 includes all of the above, including the encryption module, and many more features for QoS and general router functionality.

All of the above support a stateful firewall, IDS signature matching, syslog, etc., etc.

If you like/need a web GUI, then the 831 or 1710 are the way to go. Be sure and download Cisco's SDM for greatly improved web-based configuration and management.

Data sheets for the above can be found in the following locations:

806 [cisco.com]

831 [cisco.com]

1710 [cisco.com]

SDM [cisco.com]

So wazzup? (-1, Flamebait)

Anonymous Coward | more than 9 years ago | (#11802268)

So, is this about how to make your pirate phone calls work better while your pirate downloads are running?

Linksys (0)

Anonymous Coward | more than 9 years ago | (#11809060)

BEFSR81 and WRT54G both have QoS configs and both work fine. The big problem with VoIP on a home LAN is you'll have an awful latency problem when using fast connections with the likes of bittorrent.

If you're using Vonage... (1)

PyroMosh (287149) | more than 9 years ago | (#11827649)

Then you can't go wrong with either the Linksys RT31P2 [bestbuy.com] (Wired) or the WRT54GP2 [bestbuy.com] (Wireless B/G).

Both are combinaton routers / ATAs in one device, so QOS is quick and seamless.

Only down side that I can see is that they only have three physical ethernet ports each (not counting the WAN port), so if your wired network is more than three nodes, you'll need a switch or some other additional solution.

The firmware even lets you control QOS further, by connection (LAN port 1, 2, 3, etc), by "application" (FTP, HTTP, Telnet, etc), or by specific port numbers.

Of course both these devices are proprietary and won't work (as ATAs at least) with VoIP providers other than Vonage. But if you want, I suppose you could jerry rig something with annother ATA as an end point, just using these for the QOS control.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>