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.