Feature Request: RADIUS 'test'

nickb · Fri Sep 15, 2006 12:33 am

Under tools, or perhaps as a function of configuring a radius item, it would be very hand to be able to specify a username and password, and force a "test" of the radius server. Basically just use the supplied information and try to authenticate.

Could be a very helpful troubleshooting tool. Ideally, it would show all of the output of the radius server such as attribute replies and such.

Fri Sep 15, 2006 8:41 am

Right now you are able to switch on 'radius,debug' logs, that provide very detailed information about information exchange between RouterOS RADIUS client and RADIUS server.
'/system logging add action=memory topics=radius,debug'.

freebird · Fri Sep 15, 2006 9:03 am

Have a look at this little windows app. Its a nice and free RADIUS Test
util:

ntradping http://www.novell.com/coolsolutions/too ... adping.zip

seandsl
--

nickb · Fri Sep 29, 2006 8:56 pm

The point is not to test the radius server, but to make sure that the particular router you are troubleshooting is properly communicating with the radius server.

Technical Droid: "The user can't authenticate, they're getting a 678 error"
Admin Droid: "Just a second..." <clicks "test radius server"> "Looks like it's not communicating with the radius server, i'll check it out"

This would be handy in a lot of ways: View the actual attributes that the router is receiving, make sure that it's working (and you didn't mistype a key or address) before trying to authenticate a customer, troubleshoot a problem when a customer is having an issue logging in...

freebird · Fri Sep 29, 2006 11:22 pm

Why don't you start your RADIUS server in debug mode. You will
see everything MT sends and everything the RADIUS replies ...

I don't see a better "test tool" than that ...

seandsl
--

BrianHiggins · Sun Oct 01, 2006 6:12 am

Why don't you start your RADIUS server in debug mode.

not all radius servers have that option...

*edit*
this feature would have saved me 2 hours of time this morning troubleshooting a problem...

mcluver · Thu Jun 24, 2010 9:45 pm

I agree with the other posts that this feature would be quite handy, I know that there are numerous times I would love to just click a test button to ensure the RADIUS communication is passing through my labyrinth of security

fewi · Sat Aug 14, 2010 4:51 pm

I third that request. Having that tool halves a problem domain. Is the issue with the user talking to the NAS or with the NAS talking to the AAA server? By forcing a credential test from the NAS you can immediately tell without having to walk the user through simulating a test.

shelbynetworks · Tue Jan 18, 2011 6:05 am

I fourth!

amphigory · Thu Jun 09, 2011 1:07 am

I'd like this feature too. Some radius servers filter by IP address, and you *can't* test from anywhere but the router.

Muqatil · Thu Jun 09, 2011 1:50 am

crcaicedo · Tue Dec 27, 2011 10:03 pm

This feature can be useful to test if radius server/client connections is working, no matter if another services like hotspot are working.
+1

sup5 · Tue Dec 27, 2011 10:37 pm

A 'yes-to-all' radius implementation on RouterOS would be very nice.

So RouterOS basically would become a Radius-Server which will allow everyone to establish a connection.

This could become very handy in testing and emergence scenarios.
(Emergency: primary radius-server is down, enable 'yes-to-all' radius and make your clients happy!)

andreacoppini · Thu Jan 05, 2012 2:31 am

When I'm testing radius issues, I simply enable radius auth for management, then try to authenticate by telnet/ssh/winbox with radius credentials.

crcaicedo · Thu Jan 19, 2012 5:29 pm

When I'm testing radius issues, I simply enable radius auth for management, then try to authenticate by telnet/ssh/winbox with radius credentials.

That is not true. I enabled the radius login, and when i try the log only says 'login failure for user XX from YY via ZZ', and says *nothing* related to the specific radius/mikrotik protocol.

crcaicedo · Thu Jan 19, 2012 5:42 pm

Just now i am trying to authenticate hotspot users using freeradius and daloradius.

The freeradius server is running fine, all the external tests runs fine, including radclient, ntradping, daloradius itself, etc... but the routerboard just not connect to the radius server.

Then, i will must expend too many hours GUESSING WITH BLIND EYES what happens betweeen the routerboard and the freeradius server. Arghhh!!!!!

andreacoppini · Thu Jan 19, 2012 5:49 pm

When I'm testing radius issues, I simply enable radius auth for management, then try to authenticate by telnet/ssh/winbox with radius credentials.
That is not true. I enabled the radius login, and when i try the log only says 'login failure for user XX from YY via ZZ', and says *nothing* related to the specific radius/mikrotik protocol.

I would obviously log in with a local account and enable RADIUS logging for troubleshooting...

peterd · Mon Jan 23, 2012 5:45 pm

+1 here

gafriedman · Sun Nov 04, 2012 8:52 pm

For sure, we need to be able to force a radius test from the router for all of the reasons posted. Since Mikrotik isn't listening, can someone who is a good script writer develop a script to test the radius interaction? If I knew how to write scripts, I'd give it a go...but, alas, my script skills are primitive at best. I should think that the script should test authenticating to a particular user which the script user could easily modify.

So, how about it? The community will be forever grateful!

noib · Wed Dec 09, 2015 4:35 pm

+1, useful feature

Zorro · Thu Dec 10, 2015 5:17 am

its (in theory)possible, but what the point ?
instead you can:
1. bump verbosity of logging in both mikrotik and RADIUS or DIAMETER server up a little.
2. dump traffic and dissect it.
3. use separate radius/diameter monitoring software(i bet even Dude get something relevant before summer ~)
so far easiest 1st step to locate/trobleshoot it is: add radius "logging" rule to mikrotik and reproduce issue with analysis after.

p.s.
some server binaries - intentionally assembled with disabled/suppressed verbose output in some repositories/distros, so you had to reassemble them. not big deal(especially in toolchain-based distros(eg Gento and -alikes)).

noib · Fri Dec 11, 2015 5:01 pm

The point is just to quickly check Radius connectivity to help you diagnose a problem. As someone points out earlier in thread:
-user calling "hey i can't login"
-technician; ok, let me see. <performs radius test>. ah, i see the problem, working on it.
diagnose in 20 seconds, simple an plain, without searching in logs, which can be long in some cases

or

monitoring radius response time seen from the mikrotik client (can't have this in logs)

etc

Mikrotik device already does that, when you create your radius client, it sends some kind of ping automatically. We're just asking for a command to do that test when we need (/radius check)

Fri Dec 11, 2015 5:36 pm

I agree. One of the areas that Mikrotik truly shines in my opinion is their usefulness in remote troubleshooting.
The ability to fire off RADIUS requests from arbitrary locations is useful.
Adding radtest client to the toolbox is a good idea IMO.

Zorro · Fri Dec 18, 2015 7:54 pm

its quickly troubleshooted by temp-bumping RADIUS logging level a bit, instead.
personally i would be more thrilled by DIAMETER support instead, along with RADIUS.

PMTech · Sun Jan 29, 2017 3:46 pm

+1 for this.

I don't have a Windows box to perform a RadTest on site and some of my customers only have PPPoE routers that retry once every 5 minutes, that's a lot of time to have to wait for myself and them for me to figure out what's going on, with full logging or not!

Thanks Mikrotik for a great product, let's make it better.

ivanfm · Thu Nov 02, 2017 2:09 pm

+1

I think we should have two options :

1. Just send the request following the radius order
2. Send the request for one specific radius server

Michaelcrapse · Wed Jun 26, 2019 7:23 am

Have this exact same problem, radius works everywhere, except where it doesn't(firewall rules, etc.) but how do we make the router send out a test request? Not without bringing out clients down to force them to redial PPPoE