The Class attributed is missing in some accounting packets sent from the same NAS.

[Brian Candler]

On 07/02/2017 17:17, Selahattin Cilek wrote:
> On 07.02.2017 19:50, Brian Candler wrote:
>> On 07/02/2017 16:20, Selahattin Cilek wrote:
>>> I have been experimenting with the Class attribute to obtain the user's
>>> true identity in order to do accounting and I realised that accounting
>>> packets arriving from some users do not have this attribute.
>> Did you definitely send the Class attribute in all the Access-Accept
>> packets? Then the NAS is broken.
> I have the attribute and the in the 'radreply' table for the user:
> DIALLO Class := DIALLO
>
> However, I can't be sure if it I sen the the Class attribute in all the
> Access-Accept packets, I don't know how to make sure.
You can enable radius auth reply logs (uncomment "reply_log" in the 
post-auth section).

But in a case like this, I don't trust anything except what's on the 
wire. I would capture it with tcpdump and analyse it.

You don't want to be arguing with your NAS vendor what your config might 
or might not be doing; you want to show that you sent an Access-Accept 
containing X, and the NAS sent an Accounting-Request containing Y.

 > Can it be that MySQL cannot process the function in time, returning an
 > empty string instead?

You seem to be describing a different problem. You said that the NAS 
wasn't sending a Class attribute in the Accounting-Request packet; 
clearly you can't write something to SQL which isn't there.

As for converting hex to string: I'm not 100% sure this would work, but 
I would be inclined first to try

     update reply {
         &Tmp-String-0 := &Class
     }

and see if Tmp-String-0 contains what you need.