Limiting Bandwidth Hogs on Public Wireless Nets?

arglesnaf asks: "I'm a consultant and spend a lot of time on public wireless networks at client sites (mostly hospitals / universities), coffee shops, and hotels. Quite often, the problem is that some person is running BitTorrent and eating 100% of the bandwidth. The result is that I can't get email during the day or play World of Warcraft in the hotel. I have considered sniffing and spoofing TCP resets to free up some bandwidth but need an automated way to handle new BitTorrent connections. Does anybody have any ideas on how to automate the sniff and reset strategy, or other ways to carve out a little bandwidth from hogs on public wireless?"

Comments

Re:What if you're the network admin?

[Yonder Way]

Use OpenBSD as your gateway OS and set up queues so that BitTorrent is allowed on its well known ports, but carve out dedicated bandwidth as well for other services like imap, smtp, http, https, etc. to make sure they always have priority over torrents. You can prioritize the queues so that interactive services like ssh and http/https will pre-empt bandwidth from bulk transfer services like BitTorrent and ftp. The amount of control you have with pf is any geek's dream. You can even go so far as to say that hosts running Windows get put in a lower priority queue than hosts running anything else. :)

um, I'm a little supprised...

[josepha48]

.. that you are asking that in public. What you are asking to do is possibly against the computer abuse and fraud act. You are asking to disrupt someone elses connection by 'hacking/cracking' thier traffic.

I'd suggest you go to the front desk and tell them that you are having problems with the wireless. That you are staying in this hotel because they have internet access. I'd suggest that you tell them someone needs to look into the situation or move you to another hotel. Tell them that you suspect that someone is doing something against the law ( I know running bit torent is not against the law ) and taking up all the bandwidth. Who knows you can drop in the comment, I think that someone is running an unlawful site and allowing people to download pirated movies and that the MPAA and RIAA may come after the hotel and sue them. That would get their attention.

Complaining often works!

lower your mtu or go to starbucks

[ufnoise]

If you reduce your mtu, you might be able to squeeze some packets through and reduce latency. At least that is what I did when sharing a 56K modem connection. This also helps when your webbrowser is trying to download multiple images simultaneously.

Otherwise, go to Starbucks and pay $.10 cents a minute, because hardly anyone else will.

Re:That's not the question

[Ex Machina]

The excellent network attack package dsniff has a really cool utility tcpnice that may help.

No

[Anonymous Coward]

WoW is actually quite low bandwidth, on par with web browsing. Doesn't often hit 3k per sec. WoW would be playable on a 28.8 modem if your latency is low enough.

Re:*chuckle*

[bucky0]

That would be really ironic and funny if that was the argument against NN at all.

The argument about NN isn't about whether or not ISPs should be able to give certain type of traffic greater priority over the others (I.E. making VOIP take higher priority over HTTP)

The argument about NN is whether or not ISPs should be allowed to give certain organizations higher priority than others. What the submitter is talking about is prioritising HTTP over Bittorrent, which most wouldn't disagree about. What NN supporters are talking about is whether or not Comcast should be allowed to throttle back Vonage or Skype connections and give preference to their own VOIP service.

It's a small point, but significant, if you run it through your head.

-cheers

D-Link DSA-3100 works great

[transporter_ii]

It is more expensive than an old computer with OpenBSD on it, but it very simple to set up and is very easy to limit the speed of users by class.

We had a hotel with a 1.5Mb wireless connection that had a movie downloader just hammering us night and day. Not only was it killing the service for other users at the hotel, it was killing service for other users all over our wireless network.

Solution: We talked the hotel into getting a D-LINK DSA-3100. I had it installed in an afternoon, the hotel had a captive portal to boot, and everyone got a smaller but much fairer share of the bandwidth.

We have not had hardly a single issue with that hotel since the router was installed.

And note that this router replaced a semi-high-dollar secure router...that hung up under heavy traffic left and right.

Transporter_ii

Example script

[autocracy]

I use these settings for iptables and tc on my network gateway box for ensuring that even when it's under heavy upload & download conditions, latency will still be low (my ssh sessions used to kind of suck). The idea is the link can always be fully utilized, no one grouping of traffic gets the entire reservation group, and things should (and have) remained fast for all. If you can't figure this out between the advanced ip routing documentation (google) and my script, get in touch with me and I'd be happy to consult for your client to implement a suitable solution.

# cat /etc/network/br0-up.sh
#!/bin/sh
#Masquerade ball!
iptables -t nat -F
iptables -t mangle -F
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE

#Setup general policing goodness
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 365kbit

#General traffic
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 120kbit ceil 365kbit prio 2
#Limit general traffic backlog
tc qdisc add dev eth0 parent 1:10 handle 100: bfifo limit 12000b

#Priority (small) traffic -- UDP, small SSH, ICMP, small ACK, SYNs
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 120kbit prio 0

#Common bulk interactives
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 125kbit ceil 365kbit prio 2
tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10

#Let iptables tag things
#Prority (small) queue
tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw flowid 1:11
#HTTP Queue
tc filter add dev eth0 protocol ip parent 1:0 prio 2 handle 2 fw flowid 1:12

#Small packets are fast packets
iptables -t mangle -A POSTROUTING -m length --length 0:128 -j MARK --set-mark 0x1
iptables -t mangle -A POSTROUTING -m length --length 0:128 -j RETURN
iptables -t mangle -A POSTROUTING -p icmp -j MARK --set-mark 0x1
#certain ports get higher traffic ratings
iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j MARK --set-mark 0x2
iptables -t mangle -A POSTROUTING -p tcp --dport 443 -j MARK --set-mark 0x2
iptables -t mangle -A POSTROUTING -p tcp --dport 5190 -j MARK --set-mark 0x2
iptables -t mangle -A POSTROUTING -p tcp --sport 22 -j MARK --set-mark 0x2
iptables -t mangle -A POSTROUTING -p tcp --dport 22 -j MARK --set-mark 0x2
#DNS gets the faster lane
iptables -t mangle -A POSTROUTING -p udp --dport 53 -j MARK --set-mark 0x1