AltostratusIt 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
...
AltostratusThat 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.
NacreousHave 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"
}