Forum Discussion
adamm
Altostratus
AltostratusRadius Persistence iRule error (bad field specifier)
Having some difficulties implementing a hash persistence irule for Radius auth.
when CLIENT_ACCEPTED {
binary scan [UDP::payload] ccSH32cc code ident len auth attr_code1 attr_len1
set index 22
while { $index < $len } {
set hsize [expr ( $attr_len1 - 2 ) * 2]
binary scan [UDP::payload] @${index}H${hsize}cc attr_value next_attr_code2 next_attr_len2
# If it is Calling-Station-Id (31) attribute...
if { $attr_code1 == 31 } {
persist uie $attr_value 30
return
}
set index [ expr { $index + $attr_len1 } ]
set attr_len1 $next_attr_len2
set attr_code1 $next_attr_code2
}
}
Utilizing this iRule results in the below error:
err tmm[29577]: 01220001:3: TCL error: /Common/Radius_CallingStationId <CLIENT_ACCEPTED> - bad field specifier "-" while executing "binary scan [UDP::payload] @${index}H${hsize}cc attr_value next_attr_code2 next_attr_len2"
I can't find the "-" specifier it's referencing from the line:
binary scan [UDP::payload] @${index}H${hsize}cc attr_value next_attr_code2 next_attr_len2
Any help would be much appreciated.
Edit: Also getting these errors:
err tmm1[29577]: 01220001:3: TCL error: /Common/Radius_CallingStationId <CLIENT_ACCEPTED> - can't read "next_attr_len2": no such variable while executing "set attr_len1 $next_attr_len2"
It could be that the ${hsize} variable is being set to a negative integer. This could happen at the first binary scan the attr_len1 variable is being set to 0 or 1.
So if attr_len1 is set to 1, then hsize becomes '-2', because (1 -2) * 2 = -2.
Could you add an extra log line to your code to see what value is set to the attr_len1 variable?
when CLIENT_ACCEPTED { binary scan [UDP::payload] ccSH32cc code ident len auth attr_code1 attr_len1 log local0. "DEBUG: attr_len1 = $attr_len1" set index 22 ...
adammGreat idea, doing that now. Thanks.
- adamm
That shows the cause of the "-" bad field specifier error:
info tmm[29577]: Rule /Common/Radius_CallingStationId <CLIENT_ACCEPTED>: DEBUG: attr_len1 = 0 err tmm[29577]: 01220001:3: TCL error: /Common/Radius_CallingStationId <CLIENT_ACCEPTED> - bad field specifier "-" while executing "binary scan [UDP::payload] @${index}H${hsize}cc attr_value next_attr_code2 next_attr_len2"But there's nothing yet for the other error:
info tmm3[29577]: Rule /Common/Radius_CallingStationId <CLIENT_ACCEPTED>: DEBUG: attr_len1 = 67 err tmm3[29577]: 01220001:3: TCL error: /Common/Radius_CallingStationId <CLIENT_ACCEPTED> - can't read "next_attr_len2": no such variable while executing "set attr_len1 $next_attr_len2"Looking for other logging options to figure it out.
Lee_SutcliffeNacreous
Have you tried putting the binary scan in a catch, it may explain why the $next_attr_len2 variable is not set
if {[catch {binary scan [UDP::payload] @${index}H${hsize}cc attr_value next_attr_code2 next_attr_len2} catchErr ]} { log local0. "binary scan failed! ERROR: $catchErr" }
anicosiaNimbostratus
I was dealing the same irule from the Cisco page and troubleshooting with a coworker. The problem was when length exceeded 255, hsize became a negative number as implied above and the looped binary scan broke. In those cases we added 256 to return the proper value for the next length. The following code specifically was added in order to fix the case for either variable. Sharing in case someone else comes across this page when troubleshooting the same thing.
next_attr_len2 = $next_attr_len2"
if { $next_attr_code2 < 0 } {
set next_attr_code2 [ expr { 256 + $next_attr_code2 } ]
}
if { $next_attr_len2 < 0 } {
set next_attr_len2 [ expr { 256 + $next_attr_len2 } ]
}
Here was the full rule (with a few commented-out debug logging that helped us get there)
when CLIENT_ACCEPTED {
binary scan [UDP::payload] ccSH32cc code ident len auth attr_code1 attr_len1
set index 22
while { $index < $len } {
# log local0. "DEBUG: $attr_code1 = $attr_len1 (top of loop)"
set hsize [expr ( $attr_len1 - 2 ) * 2]
binary scan [UDP::payload] @${index}H${hsize}cc attr_value next_attr_code2 next_attr_len2
# log local0. "DEBUG: attr_value = $attr_value , next_attr_code2 = $next_attr_code2 , next_attr_len2 = $next_attr_len2"
if { $next_attr_code2 < 0 } {
set next_attr_code2 [ expr { 256 + $next_attr_code2 } ]
# log local0. "DEBUG: NEW next_attr_code2 = $next_attr_code2"
}
if { $next_attr_len2 < 0 } {
set next_attr_len2 [ expr { 256 + $next_attr_len2 } ]
# log local0. "DEBUG: NEW next_attr_len2 = $next_attr_len2"
}
# If it is Calling-Station-Id (31) attribute...
if { $attr_code1 == 31 } {
persist uie $attr_value 30
return
}
set index [ expr $index + $attr_len1 ]
set attr_len1 $next_attr_len2
set attr_code1 $next_attr_code2
}
}
Maybe you could use another Radius persisting iRule? I've been using the following:
- add an radius service profile to the virtual server.
- create an universal persistence profile and use the following iRule:
when CLIENT_ACCEPTED { set framed_ip [RADIUS::avp 8 ip4] set calling_station_id [RADIUS::avp 31 "string"] persist uie "$calling_station_id:$framed_ip" }- Add the universal persistence profile to the virtual server.
- adamm
I likely can. I was using a canned irule recommended by Cisco for load balancing ISE PSNs for MAB authentication. Since it's recommended, I was curious as to why I was having so many issues with it. It's also a good chance to learn.
I will troubleshoot this a bit more for learning if nothing else and may implement your recommendation in the end. Thanks much for your help.
ewwHi Niels van Sluis
We are struggling with the iRules on LTM 15.5. Once we use iRules we get errors on ISE. Is there anything special that needs to be done to enable the iRules to work well?
