Possible bug in unlang?

[Phil Mayers]

We've recently moved our servers to FreeRadius 2, and we've been having 
reports of some problems with our wireless service.

I investigated, and it seems the problem is the following stanza from 
the "inner-tunnel" config, which I just copied over from the default 
configs:

post-auth {
         update outer.reply {
                User-Name = "%{request:User-Name}"
         }
}

...specifically, it seems that the xlat of this string is treating 
embedded "\" as escape characters.

For example; I was unable to stop the radius server, but a tshark 
capture of a failing user shows me (C: is radius client i.e. the NAS, S: 
is packet from the radius server); note the "\\" are tshark escaping the 
data, the actual username is "IC\nyshir"

C: access-request   IC\\nyshir
S: access-challenge
C: access-request   IC\\nyshir
S: access-challenge
C: access-request   IC\\nyshir
S: access-challenge
C: access-request   IC\\nyshir
S: access-challenge
C: access-request   IC\\nyshir
S: access-challenge
C: access-request   IC\\nyshir
S: access-challenge
C: access-request   IC\\nyshir
S: access-challenge
C: access-request   IC\\nyshir
S: access-challenge
C: access-request   IC\\nyshir
S: access-challenge IC\x0ayshir
C: access-request   IC\x0ayshir
S: access-reject

Note that the final "access-challenge" sends back IC<newline>ayshir; the 
AP then carries this over to the next request, which fails.

I've solved that problem by removing the "update outer.reply", which 
leads me to a 2nd question - given that the "eap" module does this 
anyway (and since it uses a dumb "memcpy", correctly) why is that unlang 
statement there in the sample configs? Is it necessary?

One final thing; can I suggest the attached patch (though it should 
probably escape the data, since it comes from the user)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ident.patch
Type: text/x-patch
Size: 747 bytes
Desc: not available
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20080728/0a91dd5a/attachment.bin>