Project

General

Profile

Actions

Bug #9437

closed

Captive Portal Bandwidth Limiter application issue (Credentials Vs. MacAddr Validation)

Added by Damien Montanile over 5 years ago. Updated almost 4 years ago.

Status:
Resolved
Priority:
Normal
Category:
Captive Portal
Target version:
Start date:
03/27/2019
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:

Description

We're encountering a truly odd anomaly, and I'm not sure what to make of it. We are running 2.4.2_2, (also an issue with 2.4.2), with a Captive Portal setup for WIFI. We're noticing that Users who are logging in with their credentials (RADIUS), get the expected Bandwidth Limits that we have in place based on Firewall rules settings and Limiters. Not a problem. Works great as expected.

The problem stems from ALL users who have Mac Address Pass-Validated Filtered devices in place. They get a default Bandwidth Limitation of 2Mb up / 2Mb down. Once they're removed from Mac Pass Filtering, and login using their Radius credentials, They get the expected Bandwidth.

"Per-user bandwidth Restriction" was NOT checked in the CP configuration tab, but when I click/check it, the default auto-fill up/down ratio is 2048Kb (2Mb) up and down. Seemed like a bit of a coincidence since we don't have/use 2Mb limiters. Despite this value not being checked via Bandwidth Restriction, it is still being applied to Mac Filtered Devices.

Upon further testing of this theory, it seems that whatever I modify that setting to for "Per User Bandwidth restriction " despite it NOT being checked, those bandwidth limits are applied to anyone using Mac Address Pass-Validated Filtered devices ONLY. I realize Radius Authentication limits can be configured elsewhere, but its using our ruleset based limiters as mentioned above.

An extra kicker to this...If the Per-user Bandwidth restriction is set HIGHER than the ruleset based limiter.....The Ruleset based limiter, now being the lower bandwidth restriction, is now applied to "Mac Pass-Validated Filtered" devices. So it appears as though it’s applying whichever bandwidth limiters are hit first - the ruleset based limits, or the Captive Portal based limits, regardless of whether or not “Per-user Bandwidth Restriction” is checked in the CP configs.

Looking at the /cf/conf/config.xml file. I see the settings for bwdefaultdn and bwdefaultup are applied (or at least present) despite the checkbox not being checked.

<preauthurl></preauthurl>

<blockedmacsurl></blockedmacsurl>

<bwdefaultdn>10240</bwdefaultdn>

<bwdefaultup>5120</bwdefaultup>

To reproduce (I'm using arbitrary limits noted by an asterisk. you can use your own):

Create a 10Mb* down Limiter and 5Mb* up limiter in "Traffic Shaper"

Apply them to firewall ruleset governing outbound traffic / network on Captive Portal

Configure working Captive Portal config, and keep "Per-user Banwidth Restriction" unchecked, though check it for a moment to see the 2048Kb default as mentioned above. Do not save it as checked.

Add test device mac address to Captive Portal Mac PASS filters (leave per device bandwidth limits blank)

Confirm Internet Connectivity and do a speedtest. (Should be getting 2Mbup/down)

Remove device from MAC filters and run a speedtest again. (Ruleset based Limiters should be applied)

Edit Captive Portal Configuration, check "Per-user Bandwidth Restriction". Enter value LESS than the ruleset limiters and save.

Perform Bandwidth Test (Captive Portal Per-user Bandwidth Restriction values should be applied).

Modify Captive Portal Configuration, check "Per-user Bandwidth Restriction. Enter value GREATER than the ruleset limiters and save.

Perform Bandwidth Test (Ruleset Limiters should now be applied).

Actions #1

Updated by Jim Pingle about 5 years ago

  • Category set to Captive Portal
Actions #2

Updated by Viktor Gurov over 4 years ago

Actions #3

Updated by Jim Pingle over 4 years ago

  • Status changed from New to Pull Request Review
  • Target version set to 2.5.0
Actions #4

Updated by Renato Botelho almost 4 years ago

  • Status changed from Pull Request Review to Feedback
  • Assignee set to Renato Botelho
  • % Done changed from 0 to 100

PR was merged in June

Actions #5

Updated by Anonymous almost 4 years ago

  • Assignee changed from Renato Botelho to Damien Montanile
Actions #6

Updated by Viktor Gurov almost 4 years ago

  • Status changed from Feedback to Resolved

works as expected on 2.5.0.a.20201207.0250

Actions

Also available in: Atom PDF