P2P Traffic Shaping For Home Use?

An anonymous reader writes "My housemate uses an aggressive P2P client, that when in use makes the Internet unusable for everyone else connected to the network. After hearing about various ISPs shaping traffic to reduce P2P traffic, I was wondering if there was a solution for managing P2P traffic on a home network. I have a Linksys WRT54G available for hacking. Can Slashdot recommend a way to reduce the impact of P2P on my network and make it usable again?"

Comments

How about ask?

[Alioth]

How about just nicely explaining the problem to him, and requests he runs his P2P stuff overnight when no one is using the connection?

If that doesn't work, well, his port on the switch might mysteriously fail during waking hours.

Talk to your housemate

[Dolohov]

Seriously. An arms race is not going to solve your problem.

Obvious

[Anonymous Coward]

Beat the shit out of the fucker.

Anonymous Coward

[Anonymous Coward]

Switch to Comcast!

1st off

[atarione]

a. 1st off and most importantly make sure the internet connection isn't in your name so you are not the one who gets sued by the RIAA b. go get DD-WRT (check your WRT54G version..later one's suck) then set up the traffic shaping QoS feature. http://www.dd-wrt.com/wiki/index.php/Quality_of_Service

Easiest way: Raise QoS of OTHER traffic.

[Zarhan]

Raise priority for

    - Web (Http and https, maybe also 8080)
    - DNS (UDP:53)
    - Mail (SMTP, IMAP, POP3 (including SSL versions))
    - IRC (if you use)
    - FTP
    - SSH, Telnet
    - All TCP acknowledgement packets.
    - Maybe some gaming protocols (Directplay, WoW, etc - these unfortunately require checking docs for each game)

that way, you have whitelisted most of the "interactive" protocols that suffer from loaded link. No need to keep chasing after the latest encrypted, onion routed P2P application that happens to be flavor of the month. The biggest problem is the online gaming stuff.

All major clients, but it still requires talking..

[Nerobro]

I love how people pimp their own client. But nearly every PTP client I've touched, has bandwidth limiting. Some of them, uTorrent included, allows you to schedule your bandwidth.

The real problem here isn't traffic shaping, but about traffic courtesy. Your housemate may not know how much trouble their causing. Talk to them. Get them to set their max speeds to 1/2 or 1/4 of the available bandwidth.

They may be surprised when their OWN web browsing gets better.

Yet this does all hinge on you talking to said housemate. Go talk. I've had the "talk" and been the person talking to the housemate. It usually works out well.

Re:In the days of Napster

[Anonymous Coward]

Of course, you could try talking to him, but then if he refuses it ruins the credability of the above plan somewhat. Not at all. After he refuses to talk about it, you block his traffic then when he says something's up you say "Shit! I tried to talk to you about this but you wouldn't listen. I knew this would happen. The Cable Company must be fucking with our access. They've probably told the police too! Right... you hide in the attic until this blows over. I'll say you've fled to Brazil or something."

Just speak to him!

[drspliff]

My housemate has a machine setup for bittorrent, when we first moved in together it was very annoying as he seemed oblivious that running it all the time meant that my connections were slow, dropping all the time & unusable.

So I spoke to him, you know - in a rational way. It's now scheduled for the nights & days when we're either asleep or at work with a few hours in between & most of the weekends where it's either throttled down to 10k/s (by uTorrent) or stopped completely.

On top of that we've got a Smoothwall box with packet prioritization for ssh/web/email/im etc. but no bandwidth throttling.

At the end of the day, if you cant come to an agreement then it's probably just gonna get worse for you two and there's nothing you can do to stop him being an asshole.

I use a DLink DLG-4300

[QX-Mat]

http://games.dlink.com/products/?pid=370

Works well, but is rather expensive. Has an oversized NAT table to help with UDP server pings, so this will remedy and torrent problems you might have with your current setup.

QoS system is fairly flexible with an intuitive GUI and many preconfigured service options.

Has an option to pack the output frames completely (harms XBox Live possibly) as well as delay non-prio packets in favour of VOIP/gaming/as you configure.

Matt

OpenBSD Packet Filter

[Piranhaa]

http://www.openbsd.org/cgi-bin/man.cgi?query=pf.conf 'nuf said

Re:It's simple with OpenWrt

[corsec67]

Or install Tomato and go to the QOS tab. It is pretty simple to get QOS going on Tomato

Re:Need more input!

[mrsteveman1]

Any WRT54G model before v5 can be modified easily, v5+ can sometimes be modified with DD-WRT. And of course they still sell the GL, which is quite worth the price ($60 on amazon) because of how useful it becomes with this alternate firmware. The GL can also be modified and has the advantage of still being sold under a clear model number, so you know you can mod it, unlike others.

On the other hand, there is awesome shaping available in tomato firmware, it can classify traffic and show you what percentage of your traffic was in each class.

http://www.polarcloud.com/img/ssqosc108.png
http://www.polarcloud.com/img/ssqosg108.png
http://www.polarcloud.com/tomato

Linux, iptables and Traffic Control (tc)

[xororand]

As someone mentioned in a previous post, it's much easier to just whitelist priorized services such as ssh, telnet or gaming protocols than wasting too much CPU cycles on detecting obscure P2P protocols with layer 7 filters.

Personally, I use iptables & tc to setup a simple HTB (Hierarchical Token Bucket filter) system with 3 priority levels:

- Interactive: SSH (with Minimize-Delay TOS-Flag), Telnet, Jabber, ...
- Medium: HTTP, IMAP, SMTP, POP3, ...
- Low: All the rest

Shaping the upload speed is my only concern. All 3 classes may use the complete upload bandwidth. The interactive HTB class gets a guaranteed 90% of the bandwidth and a high burst value. The lowest HTB class has a burst of 0 and about 5% guaranteed upload speed.

While this is only primitive setup, it allows lag-free ssh with an unlimited upload in the background.

An in-depth how-to about the Linux Traffic Control system: http://www.tldp.org/HOWTO/Traffic-Control-HOWTO/index.html

A short pragmatic example using HTB & SFQ can be found here: http://gentoo-wiki.com/HOWTO_Packet_Shaping

Re:Need more input!

[Shakrai]

but you want to tell everything you know about "P2P traffic shaping for home use" and be useful to more people.

This won't be directly helpful to the submitter (he's working with a WRT54G), but this is how I do it in Linux. Set up the shaping rules with tc. Classify traffic with iptables. Examples follow:

(in /etc/ppp/ip-up -- would likely be rc.local or similar file for a cable modem user who doesn't use ppp)

# ADSL connection is 832,000 bits/s on upload.
#
# We rate limit to 632,320 bits/s (76%) to account for ATM/PPPoE/IP protocol overhead.
#
# This is broken up as follows:
#
# 72,000 bits/s for TCP Acks (keep our downloads fast even if upload is pegged)
# 35,000 bits/s for interactive packets (icmp echo/reply, tcp syns, network time protocol, small ssh packets -- only small ones so we don't prioritize scp transfers)
# 236,500 bits/s for priority traffic (traffic to my work VPN)
# 236,500 bits/s for normal traffic (this is the default)
# 35,000 bits/s for low priority traffic (udp trackers in bittorrent)
# 35,000 bits/s for idle priority traffic (bittorrent uploads)

/sbin/tc qdisc add dev $1 root handle 1: htb default 50
/sbin/tc class add dev $1 parent 1: classid 1:1 htb rate 632320bit ceil 632320bit
/sbin/tc class add dev $1 parent 1:1 classid 1:20 htb prio 1 rate 72000bit ceil 632320bit quantum 1454
/sbin/tc class add dev $1 parent 1:1 classid 1:30 htb prio 2 rate 35000bit ceil 632320bit quantum 1454
/sbin/tc class add dev $1 parent 1:1 classid 1:40 htb prio 3 rate 227660bit ceil 632320bit
/sbin/tc class add dev $1 parent 1:1 classid 1:50 htb prio 4 rate 227660bit ceil 632320bit
/sbin/tc class add dev $1 parent 1:1 classid 1:60 htb prio 5 rate 35000bit ceil 632320bit quantum 1454
/sbin/tc class add dev $1 parent 1:1 classid 1:70 htb prio 6 rate 35000bit ceil 632320bit quantum 1454

/sbin/tc qdisc add dev $1 parent 1:20 handle 20: sfq perturb 10
/sbin/tc qdisc add dev $1 parent 1:30 handle 30: sfq perturb 10
/sbin/tc qdisc add dev $1 parent 1:40 handle 40: sfq perturb 10
/sbin/tc qdisc add dev $1 parent 1:50 handle 50: sfq perturb 10
/sbin/tc qdisc add dev $1 parent 1:60 handle 60: sfq perturb 10
/sbin/tc qdisc add dev $1 parent 1:70 handle 70: sfq perturb 10

In order, those commands establish a htb scheduler with a celing of 632,320bit/s (you have to set this around 70-80% less than your actual upload to force the packets to queue at your box and not the dsl/cable modem), then establishs children underneth it for each class of traffic. The children will get AT LEAST the specified rate and when extra is available will borrow it according to their priority number. Prio 0 gets all extra bandwidth until satisifed or no more exists, then prio 1, prio 2, etc, etc.

The second set of commands attaches a fair queuing algorithm so individual connections within those classes will share the bandwidth (more) fairly.

From there it's just a matter of using iptables to classify the traffic. This example shoves all bittorrent traffic into the lowest queues. We assume that anything coming from 172.25.42.254 is bittorrent traffic because we add that as a second IP address on the client behind NAT and make Azureus bind to that IP (all other traffic goes out on the default IP).

iptables -t mangle -N LOW
iptables -t mangle -N IDLE
iptables -t mangle -A LOW -j CLASSIFY --set-class 1:60
iptables -t mangle -A LOW -j RETURN
iptables -t mangle -A IDLE -j CLASSIFY --set-class 1:70
iptables -t mangle -A IDLE -j RETURN
iptables -t mangle -A FORWARD -p udp -s 172.25.42.254 -j LOW
iptables -t mangle -A FORWARD -p udp -s 172.25.42.254 -j RETURN
iptables -t mangle -A FORWARD -p tcp -s 172.25.42.254 -j IDLE
iptables -t mangle -A FORWARD -p tcp -s 172.25.42.254 -j RETURN

Those commands