On Mar 31, 2021, at 8:30 AM, Chris Wopat <me@falz.net> wrote:
To clarify, you're using some BS reply-item, which is in some vendor dictionary just to store this variable string, then comparing that at the end? In theory this sounds like it would resolve this for us.
Looking at the dictionary file, it says to use between 3000 and 4000 for local attributes, perhaps just plopping something like this in that file would work?
Yes That would work.
ATTRIBUTE Local-Reject-Check 3000 string
OR perhaps as an int:
ATTRIBUTE Local-Reject-Check 3000 integer
It doesn't really matter. All that matters is if it exists. Maybe make it a string, and then put the value as *why* it didn't match.
What we have now is:
network: if / elsif / elsif / (no reject currently, or it wouldn't make it to the optical check if not in network group)
optical: if / elsif / else reject
The solution you list seems sane on paper, we hadn't thought about using a reply item to store a variable for a later check, but assuming that's all possible, I think this is our winner.
Sounds like it. if network 1 ... ... else { update reply { Local-Reject-Check += "No matching network" } } if optical 1 ... ... else { update reply { Local-Reject-Check += "No matching optical" } } if (&reply:Local-Reject-Check) { reject } And that should do it. Alan DeKok.