Hi all, I'm in the process of upgrading an old 2.2.0 installation of FreeRADIUS to a more sane 3.0.17 release (stock from current CentOS). I've hit a problem while trying to migrate the MySQL module due to the way that regular expressions seem to be getting escaped, and was hoping someone could see if anything looks amiss. We have a custom attribute, My-Regex-Pattern, that is defined as a simple string. In this instance, the attribute is held within the radgroupcheck MySQL table with the following regex stored as a string: @(.+\\.)?(DOMAIN1|DOMAIN2)$ During the authorize_check_query stage, a stored procedure is successfully called and the attribute is returned along with the correct value: (1) sql: Executing select query: Call getChecks('foo@bar.com'); (1) sql: User found in radcheck table (1) sql: Conditional check items matched, merging assignment check items (1) sql: My-Regex-Pattern := "@(.+\\.)?(DOMAIN1|DOMAIN2)$" However, when that string is later expanded via Unlang, the escaping appears to break as the opening parentheses get escaped while the closing ones do not: (1) if ( &control:My-Regex-Pattern && &User-Name =~ /%{control:My-Regex-Pattern}/i ) { (1) EXPAND %{control:My-Regex-Pattern} (1) --> @\(\.\+\\.)\?\(DOMAIN1|DOMAIN2)\$ (1) ERROR: @\(\.\+\\.)\?\(DOMAIN1|DOMAIN2)\$ (1) ERROR: ^ Pattern compilation failed: unmatched parentheses (1) ERROR: Failed retrieving values required to evaluate condition The error message makes perfect sense, but I'm unclear why this is happening and whether it's a misconfiguration, a bug or simply new intended behaviour that the migration needs to adapt to use. 'correct_escapes' is set to true and the sql modules 'safe_characters' option has been left as its default value. Thanks in advance. -- Tim