Hi, This might be slightly off topic, but hoping I could get a pointer here. I am trying to use an openvpn talking to radius. I want the openvpn server to be able to receive a COA/DISCONNECT packet. The first idea I came up with was to try and get freeradius to receive the packet, then using rlm_perl do whatever I want after examining the packet. I realize that freeradius is not designed to do this, but I was hoping either the atuhentication of accounting module could give the packet to my own perl script to then "parse" and act upon. 1) Can anyone think of a way how freeradius might receive the packet for me and then pass it to perl for me to act on? or 2) Is anyone aware of other software that might listen on the coa port 1700/3799, receive a packet, parse it somehow and call my script to "disconnect" the client. i.e. a "disconnect server". as per http://wiki.freeradius.org/DM Thanks! -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
Johan Meiring wrote:
The first idea I came up with was to try and get freeradius to receive the packet, then using rlm_perl do whatever I want after examining the packet.
Unfortunately, FreeRADIUS doesn't currently receive CoA packets. This functionality is expected to be added this year. What is generating the CoA packets?
1) Can anyone think of a way how freeradius might receive the packet for me and then pass it to perl for me to act on?
Code changes.
2) Is anyone aware of other software that might listen on the coa port 1700/3799, receive a packet, parse it somehow and call my script to "disconnect" the client. i.e. a "disconnect server". as per http://wiki.freeradius.org/DM
There isn't much. Alan DeKok.
Alan DeKok wrote:
Johan Meiring wrote:
The first idea I came up with was to try and get freeradius to receive the packet, then using rlm_perl do whatever I want after examining the packet.
Unfortunately, FreeRADIUS doesn't currently receive CoA packets. This functionality is expected to be added this year.
Any idea when?
What is generating the CoA packets?
It will also be freeradius (on a different machine), the actual radius server.
1) Can anyone think of a way how freeradius might receive the packet for me and then pass it to perl for me to act on?
Code changes.
Looking at the source, I see that it can at least identify the packets, but then ignores them, because they are not authentication/accounting packets. I dit a minor change, to not ignore the packet and pass it to the accounting module, but then the accounding module crashed. Last bit of radius -X --------------------- radius/radacct/accounting-20090108 expand: %t -> Thu Jan 8 16:41:57 2009 ++[detail] returns ok Invalid Accounting Packet ++[perl] returns invalid } # server amobia_hotspot Unknown packet type 40 [event.c:1691] Unknown packet type ---------------------- As my C skills is non existant, I can only do "copy and paste" type programming. I could attempt some changes with some pointers......
2) Is anyone aware of other software that might listen on the coa port 1700/3799, receive a packet, parse it somehow and call my script to "disconnect" the client. i.e. a "disconnect server". as per http://wiki.freeradius.org/DM
There isn't much.
Not much or nothing?
Alan DeKok. -
Thanks!
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
Johan Meiring wrote:
Any idea when?
There is no defined time frame.
What is generating the CoA packets?
It will also be freeradius (on a different machine), the actual radius server.
In the short term, alternatives are things like shell scripts.
Looking at the source, I see that it can at least identify the packets, but then ignores them, because they are not authentication/accounting packets.
It doesn't listen on port 3799, either. That code needs to be added.
I dit a minor change, to not ignore the packet and pass it to the accounting module, but then the accounding module crashed.
Well... yes. There are many, many, other changes that need to be made.
2) Is anyone aware of other software that might listen on the coa port 1700/3799, receive a packet, parse it somehow and call my script to "disconnect" the client. i.e. a "disconnect server". as per http://wiki.freeradius.org/DM
There isn't much.
Not much or nothing?
None freely available that I know of. Alan DeKok.
On Thu, Jan 8, 2009 at 1:28 PM, Alan DeKok <aland@deployingradius.com> wrote:
Johan Meiring wrote:
Any idea when?
There is no defined time frame.
What is generating the CoA packets?
It will also be freeradius (on a different machine), the actual radius server.
In the short term, alternatives are things like shell scripts.
Looking at the source, I see that it can at least identify the packets, but then ignores them, because they are not authentication/accounting packets.
It doesn't listen on port 3799, either. That code needs to be added.
I dit a minor change, to not ignore the packet and pass it to the accounting module, but then the accounding module crashed.
Well... yes. There are many, many, other changes that need to be made.
2) Is anyone aware of other software that might listen on the coa port 1700/3799, receive a packet, parse it somehow and call my script to "disconnect" the client. i.e. a "disconnect server". as per http://wiki.freeradius.org/DM
There isn't much.
Not much or nothing?
None freely available that I know of.
Alan DeKok. -
And what about trying to modify radiusclient-ng code? I would try to add "disconnect server" capabilities to radiusclient-ng Regards Luciano
Alan DeKok wrote:
Johan Meiring wrote:
Any idea when?
There is no defined time frame.
What is generating the CoA packets?
It will also be freeradius (on a different machine), the actual radius server.
In the short term, alternatives are things like shell scripts.
Looking at the source, I see that it can at least identify the packets, but then ignores them, because they are not authentication/accounting packets.
It doesn't listen on port 3799, either. That code needs to be added.
I dit a minor change, to not ignore the packet and pass it to the accounting module, but then the accounding module crashed.
Well... yes. There are many, many, other changes that need to be made.
2) Is anyone aware of other software that might listen on the coa port 1700/3799, receive a packet, parse it somehow and call my script to "disconnect" the client. i.e. a "disconnect server". as per http://wiki.freeradius.org/DM There isn't much. Not much or nothing?
None freely available that I know of.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
OK I did the following VERY LARGE hack.... Rember I need something that will JUST receive a DISCONNECT_REQUEST packet, run perl, and send back either a DISCONNECT_ACK or _NAK 1) I created a listen section on port 3799 in radiusd.conf for auth. 2) I changed main/listen.c by adding PW_DISCONNECT_REQUEST to the case statement to allow the packet. 3) I changed main/event.c by adding PW_DISCONNECT_REQUEST to the case statement to allow the packet. 4) I hacked main/auth.c to return a DISCONNECT_NAK/_ACK instead of an ACCESS_ACK/_REJECT. Seems to work...... Comments? -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
Johan Meiring wrote:
Alan DeKok wrote:
Johan Meiring wrote:
Any idea when?
There is no defined time frame.
What is generating the CoA packets?
It will also be freeradius (on a different machine), the actual radius server.
In the short term, alternatives are things like shell scripts.
Looking at the source, I see that it can at least identify the packets, but then ignores them, because they are not authentication/accounting packets.
It doesn't listen on port 3799, either. That code needs to be added.
I dit a minor change, to not ignore the packet and pass it to the accounting module, but then the accounding module crashed.
Well... yes. There are many, many, other changes that need to be made.
2) Is anyone aware of other software that might listen on the coa port 1700/3799, receive a packet, parse it somehow and call my script to "disconnect" the client. i.e. a "disconnect server". as per http://wiki.freeradius.org/DM There isn't much. Not much or nothing?
None freely available that I know of.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
OK I did the following VERY LARGE hack....
Rember I need something that will JUST receive a DISCONNECT_REQUEST packet, run perl, and send back either a DISCONNECT_ACK or _NAK
1) I created a listen section on port 3799 in radiusd.conf for auth. 2) I changed main/listen.c by adding PW_DISCONNECT_REQUEST to the case statement to allow the packet. 3) I changed main/event.c by adding PW_DISCONNECT_REQUEST to the case statement to allow the packet. 4) I hacked main/auth.c to return a DISCONNECT_NAK/_ACK instead of an ACCESS_ACK/_REJECT.
Seems to work......
Comments?
Ok no replies.... I'm sure it so ugly that nobody's even interested. Final question. Instead of hacking auth.c to return DISCONNECT_NAK/_ACK instead of ACCESS_ACK/_REJECT. Is there any way to force the return packet type (i.e. value that ends up in request->reply->code) to be a different packet type using rlm-perl? Thanks! -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
Johan Meiring wrote:
Ok no replies.... I'm sure it so ugly that nobody's even interested.
Or busy.
Final question.
Instead of hacking auth.c to return DISCONNECT_NAK/_ACK instead of ACCESS_ACK/_REJECT.
Is there any way to force the return packet type (i.e. value that ends up in request->reply->code) to be a different packet type using rlm-perl?
Not really. The code is pretty much hard-coded to dealing with access-request packets, and responding with access-accept/challenge/reject. This hack *will* work for you... but is definitely not recommended for wider use. A better approach is to integrate CoA functionality into the server so that it's *different* from Access-Request handling. Alan DeKok.
Alan DeKok wrote:
Johan Meiring wrote:
Ok no replies.... I'm sure it so ugly that nobody's even interested.
Or busy.
Final question.
Instead of hacking auth.c to return DISCONNECT_NAK/_ACK instead of ACCESS_ACK/_REJECT.
Is there any way to force the return packet type (i.e. value that ends up in request->reply->code) to be a different packet type using rlm-perl?
Not really. The code is pretty much hard-coded to dealing with access-request packets, and responding with access-accept/challenge/reject.
This hack *will* work for you... but is definitely not recommended for wider use.
Cool, thanks, and I agree its not for wider use...
A better approach is to integrate CoA functionality into the server so that it's *different* from Access-Request handling.
I assume this is what you are planning for later...
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
participants (3)
-
Alan DeKok -
Johan Meiring -
Luciano Afranllie