On 7/5/2017 6:19 PM, Stefan Wollny wrote:
Please: I am just curious and interested to learn about my (realistic)
options.
I had a problem where a member of the household would spend too much
time watching Netflix. Rather than blocking the traffic, I just
degraded it. Your case is a little different, but this may be useful.
I no longer have the rules enabled, but I think this is what I had:
table <netflix> { 64.120.128.0/17 66.197.128.0/17 192.173.64.0/18 \
198.45.48.0/20 108.175.32.0/20 198.38.96.0/19 23.246.0.0/18
45.57.0.0/17 \
54.236.0.0/15 23.20.0.0/14 }
# Throttle rules
queue rootqv2 on vlan2 bandwidth 1000M min 1M max 1000M
queue mainv2 parent rootqv2 bandwidth 1000M min 1M max 1000M
qlimit 100 default
queue netflixv2 parent rootqv2 bandwidth 50K min 0K max 100K
burst 10M for 10000ms qlimit 10
match out to <netflix> \
set queue netflixv2 set prio 5
match in from <netflix> \
set queue netflixv2 set prio 5
match out proto tcp from any port 443 to 10.0.2.53 \
set queue netflixv2 set prio 5
match in proto tcp from 10.0.2.53 to port 443 \
set queue netflixv2 set prio 5
The main match was for traffic to Netflix's servers; the other was
because Netflix uses AWS for iPad traffic, so that was her iPad's address.
The result was hilarious. Movies would start out in high-def, and run
for a few minutes. Then Netflix would start downgrading the video. It
would actually run for some time with absolutely awful video and audio
before buffering; I was impressed by the app's response to terrible
bandwidth.
Of course, this didn't really solve the underlying problem, and I didn't
expect it to.
Anyway, others have mentioned using cron scripts to manage rules by
time. You can maybe work around the static IP issue by setting up a
required VPN or authpf, or blocking direct access and using a proxy.
That'll at least work until they tether a phone, hack the neighbor's
wireless, or remember the game system has a web browser.
