Hi Alan,

In post-auth, save the User-Name information in a database, keyed by Acct-Session-Id. Then, update the "accounting" section to retrieve the User-Name from a database, keyed by Acct-Session-ID. I tried to do that using the cache module. I set

key = "%{Acct-Session-Id}" in the module config and then called post-auth { cache } in inner-tunnel, but that way, Acct-Session-Id expands to an empty string. Do you happen to have an example somewhere of how to use the cache module for such a short-term storage? Thanks, Nik

Alan,

If only there was some kind of debugging output which would show you what the server is doing.

If only there were less condescending and more helpful people on this mailing list.

Read the debug output. It will tell you what's going on

Seriously, if that had helped, I'd not have gone through the pain to ask here. -nik

Dominik George via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:

If only there were less condescending and more helpful people on this mailing list.

There are two things about this list which makes it exceptional among all similar open source project user lists I read: 1) the ever-present and extremely helpful core developers 2) the number of users demonstrating a complete inability to read and follow the simple and well documented problem reporting instructions It has been like that for decades. I can't explain either. But I am really grateful that the second hasn't affected the first. I have sometimes wondered what makes FreeRADIUS users extra dense, It kind of hurts, since I must admit being a FreeRADIUS user myself. Most other user groups understand that requests for more information *is* help. But FreeRADIUS users often take it as an insult, and do their best to confuse the issue instead. Why? It's like they don't want any help. They just want to complain. Which I guess is their right. There are just better places than a public mailing list for that. Maybe try shouting at a wall instead? Bjørn

On 21/07/2026 13:36, Dominik George via Freeradius-Users wrote:

I'd happily provide any debug information there is, if I had the tiniest idea of what to look out for.

You should have received a link to this when you subscribed to the list: https://wiki.freeradius.org/guide/Users-Mailing-List There's no need to try and look out for the right bit of debug output to send. People nearly always send what they think is useful, which often isn't (or not complete enough), and then we get annoyed about not having the right information to be able to help. This happens a lot, hence the rapid descent into frustration. Post *everything* as explained in the link above, and then people will look through it and usually give a quick answer. (If you're not comfortable with that, e.g. especially it's a live system, then either replicate the problem on a test system or skim through and remove any sensitive info first, noting this might affect the ability to help.) -- Matthew

On Jul 21, 2026, at 3:40 PM, Brian Julin <BJulin@clarku.edu> wrote:

I think there are two factors that keep people from doing so, and both share the same root cause:

I'm not so sure. I think a major reason for not posting the debug output is a belief that it won't be helpful. * "I don't know which parts are relevant, so I didn't post it" * "I read it, and I didn't see anything that seemed relevant, so I didn't post it". The analogy here is someone having car trouble. No one has car trouble, and then tells their mechanic: * Hey, my car's acting funny. But I'm not going to tell you what's going on. You're the mechanic, you figure it out! * I brought my car in, but I'm not sure what you need to know. So I'm going to leave my car locked in the parking lot, and get angry when you tell me that you need to look under the hood.

the debug information is usually an immense really ugly looking thing that A) they would not normally post on a discussion/chat for fear of being "messy", and most people these days grew up with discussions/chats so they view a mailing list through that lens and B) Is full of details about what is most often a component of security infrastructure, where there is a concern about exposure requiring them to consider how to redact some details, some of which may not be amenable to a simple search/replace.

For (A), I would expect that people read the documentation which says "POST ALL OF THE DEBUG OUTPUT". Sadly, that expectant is often wrong. Even worse, I have no idea *where* we need to add more documentation, so that people will find it and read it. From what I can tell, there is a non-negligible set of people who have religious objections to reading documentation. For (B), I would expect that people be able to read the debug output for things they care about. e.g. secrets, IP addresses, etc. Even if you don't understand the output, it should be trivial to use "grep" to search for things. Or, people should be capable of setting up test accounts with fake names. But that don't happen, either.

Some sort of interactive post-processor for the debug input to pretty it up, clean out the true cruft, perform redactions/aliasing on any exposed server names or addresses, and maybe point out a few common issues if it sees them... might be a worthwhile endeavor.

That would be nice, but at this point no one is going to contribute it. The people who need it won't write it, and the people who don't need it are busy with other things. Alan DeKok.

Dominik George via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:

I tried to do that using the cache module. I set key = "%{Acct-Session-Id}" in the module config and then called

post-auth { cache } in inner-tunnel, but that way, Acct-Session-Id expands to an empty string.

Do you happen to have an example somewhere of how to use the cache module for such a short-term storage?

If your Acct-Session-Id is in the outer session and your username is in the inner session, fist, get them into a variable of the same name, because in one case (Auth) your variable is named "outer.request:Acct-Session-Id" and in the other just "Acct-Session-Id". You need the key = "%{whatever}" statement to always find the value at the same name, (Or use a conditional expansion syntax there). Pay attention in debug logs to which list attributes are in (control/request/reply/outer.request etc) So copy outer:Acct_Session-Id into your inner tunnel request, then run the cache module: update request { Acct-Session-Id := "%{outer.request:Acct-Session-Id}" } cache (and set the ttl in the cache module definition to something short, unless you also need it for Interim/Stop packets) Also, name your cache module. You will probably end up needing more than one cache eventually for some other thing. cache acctidcache { ttl = 30 ... } (then call with "acctidcache" instead of "cache") ...or alternatively set key="%{%{Acct-SessionId}:-%{outer.request:Acct-Session-Id}}" ...if that syntax works there. I've never tried that. A handy trick for debug mode, if you need to see a variable that normal debug does not show you, is an empty if statement: if ("foobar" == "%{Thing-I-Need-To-See}") { } the RHS expansion will then be verbosely logged under -X logging and you can search on "foobar" to find it quickly.