On Sun, Oct 21, 2012 at 12:25 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Sat, Oct 20, 2012 at 11:17:21PM +0700, Fajar A. Nugraha wrote:
Short version, your NAS (172.16.18.82) sends inconsistent user name. It sends "markus@kl-dfki.de" for access-request, but "markus" for accounting. Fix the NAS. Period.
I don't know about different NASes, but ours send the User-Name in the Accounting-Request that was returned to the NAS in the Access-Accept, not the User-Name that they used in the Access-Request. Therefore the result from FreeRADIUS does directly affect what is sent for Accounting.
In that case you need to tell the owner of the remote radius (172.16.3.225) to fix their system. Cause FR pretty much only proxy what they send. Sending Access-Request of id 147 to 172.16.3.225 port 1812 User-Name = "markus@kl-dfki.de" NAS-IP-Address = 172.16.18.82 ... Going to the next request Waking up in 0.9 seconds. rad_recv: Access-Accept packet from host 172.16.3.225 port 1812, id=147, length=172 User-Name = "markus" AFAIK many people on this list use eduroam (I don't, BTW). If you take some time to ask your question in a more understandable manner, they might be able to help you more. But they can't do anything if they don't even understand your question. What I don't understand is how come the reply that FR sends STILL contains User-Name. Reading raddb/attrs and raddb/modules/attr_filter, it looks like FR should never allow User-Name on Access-Accept. Did you REMOVE attr_filter.post-proxy from raddb/sites-available/default or whatever virtual server you're using? You might want to try simply REMOVE User-Name attribute from the Access-Accept packet using unlang. If you want to try this, see the man page, look for "-=". You should be able to add it in post-proxy section. -- Fajar