PortalShaper - details of scripts for a captive portal and traffic shaper

PortalShaper - details of scripts for a captive portal and traffic shaper

[Andrew Beverley]

Hi all,

I'm posting this for people's interest, in case it is of use to anybody.

I have created a set of scripts (called PortalShaper) to do the
following:

  * Act as a captive portal
  * Manage the users on the captive portal
  * Traffic shape the internet connection to optimise its speed
  * Create a "splash page" to display adverts to users
  * Load-share between multiple connections

I won't go into any details in this email, except to say that all the
above is achieved with iptables and iproute2 rules, with PHP scripts for
the captive portal web pages. It's therefore easily customised, or used
as examples.

The details of how it works are contained at:

http://andybev.com/index.php/PortalShaper

Full installation instructions for installing from scratch are contained
at:

http://andybev.com/index.php/Setting_up_a_captive_portal_from_scratch_using_Debian

If you have any comments then please let me know.

Andy

Re: PortalShaper - details of scripts for a captive portal and traffic shaper

[Andy Furniss]

Andrew Beverley wrote:
> Hi all,
>
> I'm posting this for people's interest, in case it is of use to anybody.
>
> I have created a set of scripts (called PortalShaper) to do the
> following:

>    * Traffic shape the internet connection to optimise its speed

Just looking at this bit.

Generally, I think doing Qos on low bandwidth lines is in need of 
tweaking on a per case basis, depending on requirements and the usage 
patterns of the users.

I've only ever played with my home dsl and go for game latency as top 
prio, with any bulk traffic of whatever nature easily classified.

So the points below really apply just to my personal experience - for 
other use the script looks fine and is as good as any. None are going to 
be perfect without tweaking for individual cases and getting a lot of 
users sharing low bandwidth dsl is never going to be nice.

Random observations.

I've never used squid, but it looks like it is exempt from shaping.

You could tweak things so you don't have to back off more than a few 
kbit/s on upstream and it wouldn't fail if there were lots of small 
packets. I can't say from personal use because I do it with patched TC, 
but it is possible to specify atm and an overhead with htb and tc will 
use the atm size of the packets.
The reason I don't use it is that I shape for pppoa vc mux on an eth 
interface and tc on eth sees packets as iplen + 14 so I would need a 
negative overhead. For ppp tc sees ip length. It's tricky for a general 
script, of course, because you need to know exactly the overhead to use 
which is different for different ppps and shaping interfaces.

On bulk btb classes I found it best for latency to set burst and cburst 
to 10 - effectively off (can't remember why I didn't use 1 - I know 0 
didn't work).

To get the best possible latency with htb it's best to allocate way more 
bandwidth than the class needs and set big bursts, this is not so good 
if your classification fails though.