Debugging while service is running
Dear Colleagues, Please forgive this question, but can the debugging service be ran while the radius service is running (given that the sites-enabled/default ports will be testing outside of 1812 and 1813)? Thanks.
On Sep 21, 2020, at 9:55 PM, lingctam <lingctam@hku.hk> wrote:
Please forgive this question, but can the debugging service be ran while the radius service is running (given that the sites-enabled/default ports will be testing outside of 1812 and 1813)?
Yes. See raddb/sites-available/control-socket Alan DeKok.
hi, if the config is present and done, yes - as Alan has said, look at control-socket another useful method is to have a 2nd instance of FR that listens on different ports but with the same main config etc as the production server (or just use another box or docker container etc) - then have a specific AP or switch configured to talk to only that FR instance and put your client on that. its like a little medical treatment room to see WTF the client issue is :-) alan
Alan Buxey <alan.buxey@gmail.com> writes:
if the config is present and done, yes - as Alan has said, look at control-socket
another useful method is to have a 2nd instance of FR that listens on different ports but with the same main config etc as the production server (or just use another box or docker container etc) - then have a specific AP or switch configured to talk to only that FR instance and put your client on that. its like a little medical treatment room to see WTF the client issue is :-)
I recommend anyone who hasn't yet tried it to take a deep look at the control-socket. Play with it for a while so you know what it can do. It's an incredibly powerful tool. I just love the ability to conditionally debug specific requests on a busy production server. Any production NAS would quickly produce a lot of debugging noise on your 2nd instance. The control socket let you debug just that single user with issues, or a single Calling-Station-Id or whatever conditional debug filter you want. Without touching the NAS config at all. It's just beautiful :-) But do read the the warnings in the example config. You obviously need to trust anyone with access to the control socket. Shouldn't be a big problem, since you really shouldn't allow anyone you don't trust to access your radius servers at all. Bjørn
On 9/22/20 9:02 PM, Bjørn Mork wrote:
Alan Buxey <alan.buxey@gmail.com> writes:
if the config is present and done, yes - as Alan has said, look at control-socket
another useful method is to have a 2nd instance of FR that listens on different ports but with the same main config etc as the production server (or just use another box or docker container etc) - then have a specific AP or switch configured to talk to only that FR instance and put your client on that. its like a little medical treatment room to see WTF the client issue is :-)
I recommend anyone who hasn't yet tried it to take a deep look at the control-socket. Play with it for a while so you know what it can do.
It's an incredibly powerful tool. I just love the ability to conditionally debug specific requests on a busy production server. Any production NAS would quickly produce a lot of debugging noise on your 2nd instance. The control socket let you debug just that single user with issues, or a single Calling-Station-Id or whatever conditional debug filter you want. Without touching the NAS config at all. It's just beautiful :-)
But do read the the warnings in the example config. You obviously need to trust anyone with access to the control socket. Shouldn't be a big problem, since you really shouldn't allow anyone you don't trust to access your radius servers at all.
Are there any docs about how to use that? I was never been able to use the filtering capability of radmin. Laszlo
Bjørn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
hi, don't know if documentation lurks elsewhere, I just used the radmin man page - read the examples section to get an idea of how to craft a filter for eg User-Name or client alan
participants (5)
-
Alan Buxey -
Alan DeKok -
Bjørn Mork -
lingctam -
Tornóci László