Project

General

Profile

Bug #8097

Captive Portal RADIUS bw_up/bw_down can feed a non-integer value to ipfw, resulting in incorrectly parsed throughput values

Added by Jim Pingle almost 2 years ago. Updated almost 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
Traffic Shaper
Target version:
Start date:
11/15/2017
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.4.x
Affected Architecture:
All

Description

The Limiter GUI and Captive Portal GUI locations to set bandwidth up/down enforce that the bandwidth value must be an integer, but if a value is given in a reply attribute from RADIUS, it is divided by 1000 which can lead to a non-integer float value passed to ipfw.

When this happens, ipfw appears to ignore anything after the decimal place and also ignores the bandwidth scale. For example, when passed "200.50Kbit/s", the resulting pipe ends up as 200 bits/s in the "ipfw pipe show" output. Due to the low throughput on the pipe, it appears as though the user has no connectivity.

Rounding the value to the nearest integer appears to correct the problem.

Associated revisions

Revision 7c4e07c6 (diff)
Added by Jim Pingle almost 2 years ago

Ensure that the value passed to ipfw pipes is always an integer, no matter the source. Fixes #8097

History

#1 Updated by Jim Pingle almost 2 years ago

  • Status changed from Confirmed to Feedback
  • % Done changed from 0 to 100

#2 Updated by Jim Pingle almost 2 years ago

  • % Done changed from 100 to 0

I also changed FreeRADIUS 3.x to use 1000 as its multiplier to match the 1000 used by Captive Portal: https://github.com/pfsense/FreeBSD-ports/commit/08b2e52d55ae6ba6f9265f1f96590c89c2cd46cf

#3 Updated by Jim Pingle almost 2 years ago

  • % Done changed from 0 to 100

#4 Updated by Jim Pingle almost 2 years ago

  • Subject changed from Captive Portal RADIUS bw_up/bw_down can feed a non-integer falue to ipfw, resulting in incorrectly parsed throughput values to Captive Portal RADIUS bw_up/bw_down can feed a non-integer value to ipfw, resulting in incorrectly parsed throughput values

#5 Updated by Jim Pingle almost 2 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF