When debugging a problem in prod environment, it's not possible to restart FreeRADIUS in debug mode, so we have to use a sniffer to display the RADIUS traffic on the network. However, general purpose sniffers like tcpdump or ethereal can only decode a few RADIUS attribute, while FreeRADIUS has thousands of attributes in its dictionaries. That's why I wrote a simple sniffer based on the libradius of FreeRADIUS. It prints the RADIUS packets exactly like running "radiusd -X". It can also filter the packets based on any RADIUS attributes: the sniffer accepts the same strings as the "users" file to match a packet. I think it's a very useful RADIUS debug tool. As it's easier to build the sniffer in the FreeRADIUS source tree, I've made a patch against CVS head. It is available here: http://nbk.perso.cegetel.net/radsniff.patch If people would be interested, it can be added to the CVS tree (pending Alan's approval). -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
That's why I wrote a simple sniffer based on the libradius of FreeRADIUS. It prints the RADIUS packets exactly like running "radiusd -X". It can also filter the packets based on any RADIUS attributes: the sniffer accepts the same strings as the "users" file to match a packet. I think it's a very useful RADIUS debug tool.
Nice.
As it's easier to build the sniffer in the FreeRADIUS source tree, I've made a patch against CVS head. It is available here:
Comments: - use #ifdef HAVE_FOO_H around the #includes, and wrap the whole radsniff.h in #ifdef HAVE_PCAP_H. There's some crazy system out there with libpcap, but not pcap.h, and it's admin will complain to the list. - the code you're copying from lib/radius.c could be abstracted a bit better, so you don't have to copy it. I've started down some of that path with the rad_encode, rad_sign, etc. functions. We could do more.
If people would be interested, it can be added to the CVS tree (pending Alan's approval).
Looks good to me. Also, the Ethereal people have grabbed the FreeRADIUS dictionaries whole-sale. So Ethereal can understand *most* of the attributes FreeRADIUS understands. I've still got to send them a patch to handle USR, Lucent, and Starent VSA's. But once that's done, they'll be as capable as FreeRADIUS. Alan DeKok.
Alan DeKok wrote:
Comments:
- use #ifdef HAVE_FOO_H around the #includes, and wrap the whole radsniff.h in #ifdef HAVE_PCAP_H. There's some crazy system out there with libpcap, but not pcap.h, and it's admin will complain to the list.
I've catched this case in a different manner, but it could be changed: If the autoconf test for pcap.h fails, the content of PCAP_LIBS is deleted, and radsniff.c isn't compiled at all.
- the code you're copying from lib/radius.c could be abstracted a bit better, so you don't have to copy it. I've started down some of that path with the rad_encode, rad_sign, etc. functions. We could do more.
You're right. I just copy/paste the code to get something that works without modifing the files in src/lib, but indeed it can be improved. For that purpose I've left the changed code in comments to point out what is different.
Also, the Ethereal people have grabbed the FreeRADIUS dictionaries whole-sale. So Ethereal can understand *most* of the attributes FreeRADIUS understands. I've still got to send them a patch to handle USR, Lucent, and Starent VSA's. But once that's done, they'll be as capable as FreeRADIUS.
That would be good. Ethereal displays a lot more information about the packet than I do in "radsniff". But depending on the situation it is also annoying to have 50+ lines of text for each packet when running "tethereal -V". I like better something that looks like the output of "radiusd -X". (and I like better writing a filter rule with the "users" file syntax to match a RADIUS packet) -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
I've catched this case in a different manner, but it could be changed: If the autoconf test for pcap.h fails, the content of PCAP_LIBS is deleted, and radsniff.c isn't compiled at all.
Sure, that's pretty much equivalent, barring people typing "make radsniff" on the command line. But I wouldn't worry too much about that.
You're right. I just copy/paste the code to get something that works without modifing the files in src/lib, but indeed it can be improved. For that purpose I've left the changed code in comments to point out what is different.
Commit it, and we can re-arrange trhe code later.
That would be good. Ethereal displays a lot more information about the packet than I do in "radsniff". But depending on the situation it is also annoying to have 50+ lines of text for each packet when running "tethereal -V". I like better something that looks like the output of "radiusd -X". (and I like better writing a filter rule with the "users" file syntax to match a RADIUS packet)
I agree. It could also be used as part of a test system, as Joe pointed out. Having the ability to test a configuration "live", without changing the live system is very, very, useful. Alan DeKok.
Alan DeKok wrote:
Commit it, and we can re-arrange the code later.
Done. I've added the files to the CVS.
I agree. It could also be used as part of a test system, as Joe pointed out. Having the ability to test a configuration "live", without changing the live system is very, very, useful.
Aaah, I've just thought about something: as radclient now understands pseudo-attributes like Packet-Dst-IP-Address and Packet-Dst-Port, we can match radsniff output with radclient input with trivial changes. -- Nicolas Baradakis
Nicolas Baradakis wrote:
When debugging a problem in prod environment, it's not possible to restart FreeRADIUS in debug mode, so we have to use a sniffer to display the RADIUS traffic on the network. However, general purpose sniffers like tcpdump or ethereal can only decode a few RADIUS attribute, while FreeRADIUS has thousands of attributes in its dictionaries.
That's why I wrote a simple sniffer based on the libradius of FreeRADIUS. It prints the RADIUS packets exactly like running "radiusd -X". It can also filter the packets based on any RADIUS attributes: the sniffer accepts the same strings as the "users" file to match a packet. I think it's a very useful RADIUS debug tool.
Since now you can go and replay the request to another radius server running on say port 11812
As it's easier to build the sniffer in the FreeRADIUS source tree, I've made a patch against CVS head. It is available here:
http://nbk.perso.cegetel.net/radsniff.patch
If people would be interested, it can be added to the CVS tree (pending Alan's approval).
participants (3)
-
Alan DeKok -
Joe Maimon -
Nicolas Baradakis