Last Modified: Apr 28, 2025
Affected Product(s):
BIG-IP LTM
Known Affected Versions:
11.5.4, 11.5.4 HF1, 11.5.4 HF2, 11.5.4 HF3, 11.5.4 HF4, 11.5.5, 11.5.6, 11.5.7, 11.5.8, 11.5.9, 11.5.10, 11.6.0, 11.6.0 HF1, 11.6.0 HF2, 11.6.0 HF3, 11.6.0 HF4, 11.6.0 HF5, 11.6.0 HF6, 11.6.0 HF7, 11.6.0 HF8, 11.6.1, 11.6.1 HF1, 11.6.1 HF2, 11.6.2, 11.6.2 HF1, 11.6.3, 11.6.3.1, 11.6.3.2, 11.6.3.3, 11.6.3.4, 11.6.4, 11.6.5, 11.6.5.1, 11.6.5.2, 11.6.5.3, 12.0.0, 12.0.0 HF1, 12.0.0 HF2, 12.0.0 HF3, 12.0.0 HF4, 12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2
Fixed In:
13.0.0, 12.1.2
Opened: Jun 06, 2016 Severity: 3-Major
iRules that process attribute-value pairs from RADIUS treat integers as signed when they should be treated as unsigned.
iRules using the RADIUS::avp command will not work as expected.
iRules using RADIUS::avp to retrieve data.
The result can be cast to an unsigned integer after obtaining the value, as follows: ltm rule radius_avp_integer { when CLIENT_DATA { set charid_integer [RADIUS::avp 26 "integer" index 0 vendor-id XXXXX vendor-type Y] set unsigned_charid_integer [expr {$charid_integer & 0xFFFFFFFF}] } } Note that tmm internally treats avp values as signed integers so this might not completely correct the issue.
Ensure that the system uses unsigned integers for RADIUS AVPs.