• On all previous pages about PPSK, a very important topic has hardly been addressed.
• Once we grant a user access to our network, we need a way to manage the bandwidth they consume.
• Both the Captive Portal and the PPPoE server are able to do this and have been developed with this functionality in mind.
• Giving someone access to a WiFi network does not automatically allow you to manage their bandwidth.
• Although we offer advanced features to change a user's assigned VLAN based on their usage during a certain period of time, we still need the ability to limit the speed of a VLAN.
• This is where Smart Queue Management (SQM) comes into play.
• With SQM, we can not only limit the bandwidth on an interface to the value we choose, but also manage the queues so that the user has a more pleasant online experience.

• The philosophy of RADIUSdesk is to offer a non-disruptive solution that can co-operate with other vendors.
• The following diagram shows a PPSK solution where the customer has chosen to use PFsense for NAT/DHCP and bandwidth limiting:

• We also offer the customer the option of using OpenWrt, which implements SQM.
• This can then be managed via APdesk.
• As OpenWrt can run on different architectures or even on a virtual machine, it offers us even more possibilities:
• Lets take a closer look at SQM on OpenWrt

The following sections are a short summary of information from this Wiki page (https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm) as well as our own experimenting.

• For SQM to be available in OpenWrt, you need the sqm-scripts package.
• If you also have Luci on the OpenWrt device, it is recommended to install the additional luci-app-sqm package.
• This will install the Luci SQM package which is well developed and offer you an intuitive way to apply SQM on selected interfaces using the Luci web interface.

• Essentially the SQM application in Luci manipulates the /etc/config/sqm UCI based config file and start and stop the SQM service to apply those settings.
• Lets look at a snippet of the sqm config file:

config queue 'br_ex_v104'
    option interface 'br-ex_v104'
    option enabled '1'
    option script 'piece_of_cake.qos'
    option linklayer 'none'
    option verbosity '5'
    option upload '4096'
    option download '4096'
    option debug_logging '0'
    option qdisc 'cake'

• Some items of note on this snippet:
  • The Queue discipline is CAKE. There is also other options like fq_codel which you can use should performance be an issue.
  • The upload and download values are in kbps so this snippet limits it to 4Mbps (4*1024)
  • The script used to set up the SQM (based on the settings in the /etc/config/sqm file) is *piece_of_cake.qos*.
  • The SQM section is applied to the br-ex_v104 interface which is actually a bridge.
• Lets look at the /etc/config/network file to find out more about the br-ex_v104 interface.

config device                         
    option type 'bridge'          
    option name 'br-ex_v104'      
    option stp '0'                
    list ports 'eth1.104'         
                                      
config interface 'ex_v104'            
    option device 'br-ex_v104'    
    option proto 'static'         
    option ipaddr '10.200.105.1'  
    option netmask '255.255.255.0'

• The word interface in the /etc/config/sqm section is used is a intuitive, yet it can also be applied to a device like a bridge.
• In our case the br-ex_104 bridge has one port, eth1.104. This port will receive traffic from VLAN 104 on eth1. (e.g. whn a user connects with a Private PSK and the Dynamic VLAN associated with him is 104.)
• Traffic going through this bridge will thus be throttled and managed with SQM.