Bug #8097
closed
Captive Portal RADIUS bw_up/bw_down can feed a non-integer value to ipfw, resulting in incorrectly parsed throughput values
100%
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.
Updated by Jim Pingle over 6 years ago
- Status changed from Confirmed to Feedback
- % Done changed from 0 to 100
Applied in changeset 7c4e07c625f21bb67370cffe8a6b3bd0c322fe5b.
Updated by Jim Pingle over 6 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
Updated by Jim Pingle over 6 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