No Realm in table radacct

[Fajar A. Nugraha]

On Sun, Oct 21, 2012 at 12:25 AM, Matthew Newton <mcn4 at 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 at 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 at 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