Escaped backslash in User-Name when sending Access-Accept

[Brian Julin]

> Roberto Franceschetti wrote:
 
> Mine is just a theory, but I cannot verify it until I figure out how to have the
> un-escaped ocg\cmctrf3 string being sent in the output instead of the
> current escaped one.

It probably is not escaped.  Some logs and debug outputs escape before
outputting to syslog or the screen, but some do not, so it is hard to
be sure what you are seeing without taking an actual packet dump
and looking at the actual bytes sent.

The only time you should ever have to deal with problems with unescaping
in the User-Name attribute is when you edit it by hand, for example,
if you take an inner tunnel copy of the user-name and then place
it by hand in the outer reply (which you should only do if you can trust
your NAS and the network between it to keep that secret.)

If you do such a thing, it is very hard to get an unescaped edited string back
into an attribute, because any attribute you define will be escaped when
you try to glue it back together with an xlat.  You can, however, do so
using %{1}, %{2}, %{3} etc from a regexp match.

# The following will take the User-Name from the request and put it into the reply,
# without adding any escaping.
if (User-Name =~ /(.*)/) {
   update reply {
       User-Name = "%{1}"
   }
}