I have a freeradiusd service running on my linux box. My boss would like the dude to be able to monitor the service. Our freeradius server is running on port 1812. I need to know what to send and what to receive. Thank you in advanced. I did try the default radius probe in The Dude. Let me know what it should look like.

I will pay anyone $200 for anyone that can make a probe work with freeradius. So I can monitor if freeradius is running or not. I am running on 1812 udp.

The default probe uses the following string to query the radius server, problem is nobody seems to know how this string is structured

\x01D\0,0123456789012345\x01\x06TEST\x02\x121234567890\0

From what I understand, the string is sent as a username/password set somehow which effectively does a login to the radius box, and the return from that login is then checked by the receive field which is set to "\x03D" in the default probe.

If you can play around with these bits of info you would be able to get it to work

I gave up trying to get it to work, but I'm sure it would with the right info

I hope that helps, please post if you figure it out

Regards
Paul

Believe it or not, I got it working. I shut the radius server off and I got a notification. I enabled the radius server and the dude said it was online. Would anyone donate paypal money to me if I publish it. This will help pay for the time spent on solving this issue. Thanks in advanced.

Well I'm glad you solved it, I think though that in the spirit of all support forums you would normally share your experience, take a look at the hundreds of hours people have poured into function design and probe settings for all to use.

Your call.

Regards
Paul

I had a similar problem and thought things needed to be changed as well then I came across this post from uldis on March 17, 2006

"you can change the contents of UDP packet that is sent in any way, but in
general it is not required to successfully authenticate with radius server,
dude just checks if reasonable response is received. (dude server should be
added to radius servers shared secret list)."

So I removed all the changes and created the dude in the shared secret list and it worked for me.

I got it working. I'm not using free radius though.

I set the shared secret on my server to a string of letters I found in the dude's probe and it worked.

The default radius probe in the Dude had a field marked "server" that had this string: "\x01D\0,0123456789012345\x01\x06TEST\x02\x12abcdefghijklmnop\0"
I took the abcdefghijklmnop out of it and guessed it was the secret, added it to my server with my dude server's IP address and the probe started working!

no charge

dude just checks if reasonable response is received. (dude server should be
added to radius servers shared secret list)."

So I removed all the changes and created the dude in the shared secret list and it worked for me.

.
true ... for me too
... anyway, it would be nice to know, whether and how a test-user (from an underlaying LDAP or so) could be authenticated with such a probe

I just upgraded my FreeRadius from V2 to V3. I've been using the \x01D\0,0123456789012345\x01\x06TEST\x02\x12abcdefghijklmnop\0 as my send probe on the V2 server. I used the same probe on my new V3 server which is still running in debug mode. I've notice that even though this probe works to detect if the server is up or down, it will give me errors in my error log. It also was logging a failed login attempt to my SQL table on every probe. These were undesirable side effects of probing. I decided to dig into this probe to figure out a better way of doing things. I was very surprised on how little information was available via google searches about radius packet formatting. I'm going to try to explain what I found and what tools I used to create a radius probe.

It appears most radius servers support Status-Server UDP packets. FreeRadius V3 supports this right out of the box. My goal on this probe was to confirm the radius server was accepting packets. I did not care about probing if it was authenticating users. If you need a probe that tests user authentication, you should be able to make a few modifications to this probe.

For those that just want the probe, here it is \f\xda\0&RadiusProbe12345P\x12\xf5\xdfFi\xdd)J>S\xeaF\xa5;\x9cj\xf1 You will need to use a shared secret of DudeProbe and make sure your radius server is setup to accept Status-Server packets.

How to build this probe. Let's start with the probe and work our way back. Dude formats the probe using ESC characters. \xda means the byte da, \0 means the byte 0. Taking this into consideration, the above probe is the hex character string of

0cda002652616469757350726f626531323334355012f5df4669dd294a3e53ea46a53b9c6af1

Lets break this down
0c is the Status-Server Code (12). If you wanted to do a Authentication-Request , you would use 01
da is a random ID byte. This can be anything.
0026 is the complete length of the packet. In this case 38 bytes.
52616469757350726f62653132333435 is the Request Authenticator (user defined) which has to be 16 bytes
50 is the Message-Authenticator (80) code
12 is the Attribute Value Pairs length including code and length byte for a total of 18 bytes.
f5df4669dd294a3e53ea46a53b9c6af1 is the Message-Authenticator Value and must be 16 bytes.

The issue is the Message-Authenticator is a HMAC/MD5 calculated value.

You take your full packet using 16 bytes of 00 as the Message-Authenticator and do a HMAC/MD5 hash using the secret as the key. In this case we would use
0cda002652616469757350726f62653132333435501200000000000000000000000000000000 and calculate a HMAC/MD5 using DudeProbe as the key. If you know don't know how to calculate the hash, search for HashCalc by SlavaSoft in google. That is what I downloaded to calculate the hash. This should result in
f5df4669dd294a3e53ea46a53b9c6af1. The easiest way I have found enter this in the probe is to escape everything.

\x0c\xda\x00\x26\x52\x61\x64\x69\x75\x73\x50\x72\x6f\x62\x65\x31\x32\x33\x34\x35\x50\x12\xf5\xdf\x46\x69\xdd\x29\x4a\x3e\x53\xea\x46\xa5\x3b\x9c\x6a\xf1

Once you save the probe, the dude will simplify it for you.

If all works as planned the Receive Packet should be \x02\xda. Notice the da will match the ID byte from the request packet. If you change the ID byte in the send packet, you need to make sure it matches in the receive string.

Remember if you make any changes to the packet, a new hash needs to be generated. I hope I did all the calculations correctly while I was typing.