Userland Traffic Shapper
JorgeAldoBR last edited by
After a looong time i finally started to develop the userland traffic shaper that i discussed before with some people of dev-team.
I think it is usefull for 1.2 targets because i did not see a per-ip traffic shapper option and a lot of people request it.
I have all needed classes written (in objectpascal) and just need to test.
My idea is to have a "traffic shapper bridge"
current model uses two tun/tap devices and a tcp socket;
the program starts without any rules (so no packets traverse the bridge at all).
other program connects to a port (configurable) at 127.0.0.1 (configurable) and sends commands, building pipes to allow traffic to flow at a rate.
something like :
./trafficshaperbridge <1st tun> <2nd tun> <ip><port>Controller program connects to <ip>: <port>and sends commands like these :
upstream <ip><bytes><maxbytes><rate><millisec>downstream <ip><bytes><maxbytes><rate><millisec>ex: upstream 192.168.1.20 12800 51200 10 1000
meaning : traffic going from device 2 to device 1, comming from 192.168.1.20 can transfer 12800 bytes each 100 milliseconds (= 128KByte/Sec) steady or burst (after being idle some time) at 51200 bytes each 100 milliseconds (= 512KByte/Sec). if the queue starts to get full, packets will be dropped after waiting 1 sec on the queue…
where <ip>can be the source or destination ip
bytes is the number of bytes that the token bucket receives per tick
maxbytes is the maximum number of bytes the token bucket can hold
rate is the rate (per second) the bucket is filled with <bytes>and millisec is the max number of milliseconds a packet can stay waiting, after wich it will be discarded...
upstream is from device 2 to device 1 and downstream is from device 1 to device 2
upstream traffic is classed by source ip and downstream traffic is classed by destination ip
after each command sent to the control socket, a number is returned, meaning the ID of the objects created by the command.
this is usefull for something like
delete <id>that will drop all rules relative to <id>...
So if everything works as expected it will be simple to write a PHP interface for this or to add functionality to the captive portal to allow login/logout with traffic shapping.
the "traffic shapper bridge" needs two tun/tap devices
generally /dev/tun0 and /dev/tun1
tun0/1 must be created before the application runs, with
ifconfig tun0 create
ifconfig tun1 create
and other commands to give ips, etc.
pfsense needs to add some routing to force packets to pass thru the bridge, and the 1st device (/dev/tun0) will become the lan interface of pfsense, while the real physical lan interface will be bridged with the /dev/tun1 device, this will force packets to pass thru the bridge...</id></id></bytes></ip></millisec></rate></maxbytes></bytes></ip></millisec></rate></maxbytes></bytes></ip></port></ip></port></ip>
eri-- last edited by
Sorry for breaking the party but in 2.0 we have per-ip shaping(dummynet) working!