Cashdesk module

Cashdesk is a Splynx module for processing payments. Administrator can create Cashdesk users and provide them access to the module. User is not able to change and view any customer’s data except his name/company name, invoice numbers and actual balance. The Cashdesk can be used by accountants who doesn’t have to get access to Splynx but only to process the incoming payments. It can be also used by resellers. Reseller will only see his customers and will be able to enter payments to Splynx when he receives money from a customer. Follow this link to check more information about resellers management in Splynx.

The first step for Cashdesk activation is installation. It’s performed by two following commands in Linux CLI where Splynx is installed:

apt-get update
apt-get install splynx-cashdesk

To create a Cashdesk user it’s needed to create an administrator and define him permissions to Splynx access. He can have some permissions to access Splynx or he can get 0 permission level and access Cashdesk only:

When the Cashdesk is installed, it’s available on “http://yoursplynxurl/cashdesk”.
The first screen is a login page:

Cashdesk user has logged, he can search customers based on customer’s name, login or number of invoice.


After entering the invoice number or customer name in search field, Cashdesk displays customer information with his balance and unpaid invoices.


The last step is to add the payment and write a comment.
When the payment has beed added, it appears in Splynx as a new transaction and also as a payment with comment, entered in Cashdesk.


All payments of the user “casher” can be found in History section of Cashdesk.


The tutorial for Cashdesk you can find in the video below:


Should you have any questions regarding Cashdesk module or further information is needed, please contact us or schedule a call with our engineer.

Contention in Splynx (aggregation of users)

Splynx provides the feature of contention or aggregation. This feature is used when ISP sells to the end users services with contention rate for example 1:5, 1:10 etc. Contention means that end user will share the bandwidth with other end users in his group.

Splynx operates with two types of contention: Per plan based and per router contention.

1. Plan based contention.
Let’s take a look on example.
We are selling to the end users plan 5 Mbps with contention rate 1:5. It means, that Splynx will setup the parent speed-limit of 5 Mbps and under this parent it will place 5 users with speed-limit of 5 Mbps each. What will happen in this situation: if line is free and one user starts to download/upload, he gets full 5 Mbps throughput. In case, when second user actively starts downloading, they will get 2,5 Mbps each. When all 5 users will simultaneously download with maximum speed, they will share the bandwidth.

It’s described in the image below:












We can tune a bit sharing of speed with setting up “Limit-at” or guaranteed speed. If we place 1 Mbps to each user, then all users will always get at least 1 Mbps.

In that case all 5 users will simultaneously download with 1 Mbps speed. It’s shown on a second screenshot.












What will happen in situation, when we will put 7 users on 1:5 contention plan ? Splynx will change the parent speed to 7 Mbps in this particular case, but will leave maximum speed of each user on 5 Mbps.















If you are planning to deploy Plan-based contentions, use it on central routers to achieve high amounts of users in one tree. Compare two situations – 1:5 contention tree with 5 users and two of them are hard downloaders, it means that 3 other users will never get 5 Mbps speed, because they are all under one common parent of 5 Mbps.

If we place 20 users on this contention 1:5, then parent maximum speed will be set to 20 Mbps and then two or more high downloaders will not use the whole bandwidth.


2. Router based contention.

Router based contention is used in this scenario:

Imagine that we have a wireless AP which is connected to backbone network with 30 Mbps speed. But we connected to that AP users with total possible bandwidth of 60 Mbps. What can happen in a peak time is that users will consume more traffic than can be sent through uplink. It means that wireless link can become overutilized and unstable. It’s shown in the picture below.


To prevent this situation, router based contention can be used. In Splynx each router has field “Sector/Speed limits”, where can be defined groups and administrator can put users under these groups. As a result we will achieve contention per router :















In a short video tutorial you can find how to configure Splynx and Plan based contention:

Configuration of Router based contention is shown on other video:


Blocking of non paying customers in Splynx


Splynx blocks non paying customers automatically. Also administrator can block the customer manually. When customer is put to Blocked or Inactive status, Splynx sends to router command to block him. If status is changed to Block – Splynx never cuts the service, but places the IP of end user to Address-list or give hime IP address from IP pool for blocked customers. Then administrator can create a rule on router for redirection of non-payers to a special page.

Splynx has 4 default blocking pages which are located at : http://yoursplynxurl:8101, http://yoursplynxurl:8102, http://yoursplynxurl:8103 and http://yoursplynxurl:8104

It’s a simple HTML file, which you can change via command line inside your splynx installation (SSH) at  /var/www/splynx/web/errors/ and folders 1,2,3,4 correspond to ports 8101, 8102, 8103 and 8104

Example of default blocking page is shown below :

2016-09-02 03.53.25 pm

Example of how the page can be customized :

2016-09-02 03.52.51 pm

There are 4 types of blocking scenarios :

1. Mikrotik API blocking
If you use Mikrotik based authentication – Hotspot, DHCP, Wireless or PPP, then as the first step, you should enable API blocking of users. It’s called “Disabled customers to Address-List” in Router API settings:


When customer is moved to status “Blocked”, his IP address is put to address list “SpLBL_blocked”. With setting up the rules for redirection, you can achieve that customer will see a special webpage with information why his access to the Internet was blocked.

2. Radius COA blocking
In Radius by default we also work with Addres-lists. Splynx uses names of address lists Reject_1, Reject_2, Reject_3 and Reject_4 for different type of errors. The names of address lists are configured under Config -> Networking -> Radius and also under field COA Block attributes:

2016-09-02 04.18.24 pm

3. Radius Session disconnection
The difference between Radius COA block and session blocking is that with COA session of customer is not disconnected, while in Session blocking his session is cut and user must reconnect his device.

The setting how to block user is defined in Config -> Networking -> Radius “Customer Block” and “FUP Block”:

2016-09-03 02.17.07 pm

4. Radius IP pool blocking
If customer gets IP from dynamic pool, or when NAS router is not a Mikrotik, Splynx gives to the blocked customer IP from Reject IP pools. By default these pools are 10.250.25x.0/24, but it can be changed in Config -> Networking -> Radius as shown on screenshot below:

2016-09-02 04.17.17 pm

If you use Mikrotik routers, there are 2 rules to redirect all TCP traffic to the blocking webpage and to cut all other traffic like Peer to peer connections (redirect them to router itself):

/ip firewall nat add action=dst-nat chain=dstnat protocol=tcp src-address-list=Reject_1 to-addresses= to-ports=8101
/ip firewall nat add action=redirect chain=dstnat protocol=!tcp src-address-list=Reject_1

All four methods of Splynx user blocking  you can find on our video tutorials:

Mikrotik API blocking of non payers

Radius COA blocking of non payers

Radius code disconnect (session reset)

Radius reject IP pool assignment

Should you have any questions regarding user blocking in Splynx or you just want to try it in action, feel free to contact us.