send an "coa" packet from "authorize {}" section
Hi, I need to send a COA to another NAS during the section "authorize { }", below my current approach. 1) I receive the "Access-Request" Sun Oct 4 18:19:33 2015 : Debug: (0) Received Access-Request Id 227 from 10.1.2.128:42305 to 192.168.56.90:1812 length 46 Sun Oct 4 18:19:33 2015 : Debug: (0) User-Name = "ca:de:ca:fe:00:01" Sun Oct 4 18:19:33 2015 : Debug: (0) Acct-Session-Id = "12345" Sun Oct 4 18:19:33 2015 : Debug: (0) session-state: No State attribute Sun Oct 4 18:19:33 2015 : Debug: (0) # Executing section authorize from file /etc/freeradius/sites-enabled/mcare-nas-portal Sun Oct 4 18:19:33 2015 : Debug: (0) authorize { 2) Build a "coa" packet and build to the home-server. *Sun Oct 4 18:19:33 2015 : Debug: (0) update coa {* *Sun Oct 4 18:19:33 2015 : Debug: (0) &Packet-Type := CoA-Request* *Sun Oct 4 18:19:33 2015 : Debug: (0) &Acct-Session-Id := "12345"* *Sun Oct 4 18:19:33 2015 : Debug: (0) &Home-Server-Pool := coa_pool_wifilabs* *Sun Oct 4 18:19:33 2015 : Debug: (0) } # update coa = noop* Sun Oct 4 18:19:33 2015 : Debug: (0) modsingle[authorize]: calling handled (rlm_always) for request 0 Sun Oct 4 18:19:33 2015 : Debug: (0) modsingle[authorize]: returned from handled (rlm_always) for request 0 Sun Oct 4 18:19:33 2015 : Debug: (0) [handled] = handled Sun Oct 4 18:19:33 2015 : Debug: (0) } # authorize = handled 3) From this point, I can't figure out about the best way to wait and only responds after coa feedback. Sun Oct 4 18:19:33 2015 : Debug: (0) There was no response configured: rejecting request Sun Oct 4 18:19:33 2015 : Debug: (0) Using Post-Auth-Type Reject Sun Oct 4 18:19:33 2015 : Debug: (0) Post-Auth-Type sub-section not found. Ignoring. 4) Below the behavior of home-server (mcare-nas-radius-wifilabs)... was sent with success! Sun Oct 4 18:19:33 2015 : Debug: (0) # Executing group from file /etc/freeradius/sites-enabled/mcare-nas-portal Sun Oct 4 18:19:33 2015 : Debug: (0) server mcare-nas-radius-wifilabs { Sun Oct 4 18:19:33 2015 : Debug: (0) Empty pre-proxy section in virtual server "mcare-nas-radius-wifilabs". Using default return values. Sun Oct 4 18:19:33 2015 : Debug: (0) } Sun Oct 4 18:19:33 2015 : Debug: (0) proxy: Trying to allocate ID (0/2) Sun Oct 4 18:19:33 2015 : Debug: (0) proxy: request is now in proxy hash Sun Oct 4 18:19:33 2015 : Debug: (0) proxy: allocating destination 10.11.10.22 port 1812 - Id 25 Sun Oct 4 18:19:33 2015 : Debug: (0) session-state: Nothing to cache *Sun Oct 4 18:19:33 2015 : Debug: (0) Sent CoA-Request Id 25 from 0.0.0.0:57493 <http://0.0.0.0:57493> to 10.11.10.22:1812 <http://10.11.10.22:1812> length 27* Sun Oct 4 18:19:33 2015 : Debug: (0) Acct-Session-Id := "12345" Sun Oct 4 18:19:33 2015 : Debug: (0) Delaying response for 1.000000 seconds Sun Oct 4 18:19:33 2015 : Debug: Waking up in 0.3 seconds. Sun Oct 4 18:19:33 2015 : Proxy: (0) Marking home server 10.11.10.22 port 1812 alive Sun Oct 4 18:19:33 2015 : Debug: (0) Clearing existing &reply: attributes *Sun Oct 4 18:19:33 2015 : Debug: (0) Received CoA-ACK Id 25 from 10.11.10.221812 to 192.168.56.90:57493 <http://192.168.56.90:57493> length 75* Sun Oct 4 18:19:33 2015 : Debug: (0) Reply-Message = "AAA->NOKIA() listen::type=coa,port::1812 pack-type=(CoA-Request)" 5) I would like to get the received response from home-server and threat to reponse Access-Accept (if CoA-ACK) or Access-Reject (if CoA-NAK) Sun Oct 4 18:19:33 2015 : Debug: (0) server mcare-nas-radius-wifilabs { Sun Oct 4 18:19:33 2015 : Debug: (0) # Executing section post-proxy from file /etc/freeradius/sites-enabled/mcare-nas-radius-wifilabs Sun Oct 4 18:19:33 2015 : Debug: (0) post-proxy { Sun Oct 4 18:19:33 2015 : Debug: (0) update control { Sun Oct 4 18:19:33 2015 : Debug: (0) &Auth-Type := Accept Sun Oct 4 18:19:33 2015 : Debug: (0) &Response-Packet-Type := Access-Accept Sun Oct 4 18:19:33 2015 : Debug: (0) &Packet-Type := Access-Accept Sun Oct 4 18:19:33 2015 : Debug: (0) } # update control = noop Sun Oct 4 18:19:33 2015 : Debug: (0) update request { Sun Oct 4 18:19:33 2015 : Debug: (0) &Auth-Type := Accept Sun Oct 4 18:19:33 2015 : Debug: (0) &Response-Packet-Type := Access-Accept Sun Oct 4 18:19:33 2015 : Debug: (0) &Packet-Type := Access-Accept Sun Oct 4 18:19:33 2015 : Debug: (0) } # update request = noop Sun Oct 4 18:19:33 2015 : Debug: (0) update proxy-reply { Sun Oct 4 18:19:33 2015 : Debug: (0) &Auth-Type := Accept Sun Oct 4 18:19:33 2015 : Debug: (0) &Response-Packet-Type := Access-Accept Sun Oct 4 18:19:33 2015 : Debug: (0) &Packet-Type := Access-Accept Sun Oct 4 18:19:33 2015 : Debug: (0) } # update proxy-reply = noop Sun Oct 4 18:19:33 2015 : Debug: (0) modsingle[post-proxy]: calling updated (rlm_always) for request 0 Sun Oct 4 18:19:33 2015 : Debug: (0) [handled] = handled Sun Oct 4 18:19:33 2015 : Debug: (0) } # post-proxy = handled Sun Oct 4 18:19:33 2015 : Debug: (0) } Sun Oct 4 18:19:33 2015 : Debug: (0) Cleaning up request packet ID 227 with timestamp +286 Sun Oct 4 18:19:33 2015 : Debug: Waking up in 0.1 seconds. Sun Oct 4 18:19:33 2015 : Debug: Waking up in 0.6 seconds. I have tried all lists "request", "proxy-reply" and "control".... but, don't work! Sun Oct 4 18:19:34 2015 : Debug: (0) Sending delayed response Sun Oct 4 18:19:34 2015 : Debug: (0) Sent Access-Reject Id 227 from 192.168.56.90:1812 to 10.1.2.128:42305 length 20 Sun Oct 4 18:19:34 2015 : Debug: Waking up in 3.9 seconds. Any suggestions are welcome! -- Jorge Pereira
On Oct 4, 2015, at 3:21 PM, Jorge Pereira <jpereiran@gmail.com> wrote:
I need to send a COA to another NAS during the section "authorize { }", ... 3) From this point, I can't figure out about the best way to wait and only responds after coa feedback.
You can't do that right now. Addressing that for 3.1.x might be a possibility. We're looking into fixing some of the state machine issues to make this easier. The main issue is that originating a CoA packet is not quite the same as proxying. So for a proxy, we can wait for a response. For a CoA packet, we can't. Fixing this requires changes to the server core. I'd prefer to wait until that's been cleaned up a bit before adding new behaviour. Alan DeKok.
Hi Alan, This sound bad... I will look for some other solution. btw, I believe that we need to allow the home_server to set the type like "coa+auth+acct" or other option like "all" or multiple sets (type="coa", type="auth", type="acct") Will help a lot the integration with *crap radius vendors* that listens to everything in the same port. eg: Nokia & Juniper. Currently, my solutions is changing the udp-packet like: "all packets from X of kind is UDP to port 3799, replace the DPORT to 1812".... works well, but I don`t like that. thanks for your help! -- Jorge Pereira On Sun, Oct 4, 2015 at 4:27 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 4, 2015, at 3:21 PM, Jorge Pereira <jpereiran@gmail.com> wrote:
I need to send a COA to another NAS during the section "authorize { }", ... 3) From this point, I can't figure out about the best way to wait and only responds after coa feedback.
You can't do that right now. Addressing that for 3.1.x might be a possibility. We're looking into fixing some of the state machine issues to make this easier.
The main issue is that originating a CoA packet is not quite the same as proxying. So for a proxy, we can wait for a response. For a CoA packet, we can't.
Fixing this requires changes to the server core. I'd prefer to wait until that's been cleaned up a bit before adding new behaviour.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Alan, Do you have any position about the idea? -- Jorge Pereira On Sun, Oct 4, 2015 at 4:47 PM, Jorge Pereira <jpereiran@gmail.com> wrote:
Hi Alan,
This sound bad... I will look for some other solution. btw, I believe that we need to allow the home_server to set the type like "coa+auth+acct" or other option like "all" or multiple sets (type="coa", type="auth", type="acct")
Will help a lot the integration with *crap radius vendors* that listens to everything in the same port. eg: Nokia & Juniper.
Currently, my solutions is changing the udp-packet like: "all packets from X of kind is UDP to port 3799, replace the DPORT to 1812".... works well, but I don`t like that.
thanks for your help!
-- Jorge Pereira
On Sun, Oct 4, 2015 at 4:27 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 4, 2015, at 3:21 PM, Jorge Pereira <jpereiran@gmail.com> wrote:
I need to send a COA to another NAS during the section "authorize { }", ... 3) From this point, I can't figure out about the best way to wait and only responds after coa feedback.
You can't do that right now. Addressing that for 3.1.x might be a possibility. We're looking into fixing some of the state machine issues to make this easier.
The main issue is that originating a CoA packet is not quite the same as proxying. So for a proxy, we can wait for a response. For a CoA packet, we can't.
Fixing this requires changes to the server core. I'd prefer to wait until that's been cleaned up a bit before adding new behaviour.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Sun, Oct 04, 2015 at 04:47:55PM -0300, Jorge Pereira wrote:
This sound bad... I will look for some other solution. btw, I believe
Very nasty hack, but you could always exec a script as part of authorize that calls radclient to send the coa and wait for a response. The script will need to make sure it times out quickly if it doens't receive an answer, and exec like this isn't very fast so if you've got a lot of auths/s then it'll bog the server down, but it should work. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi Matthew, I know that is a nasty hack, but the problems are the "fancy vendors" that has big and famous appliance completely out of standards. my approach about this, It replaces the process of my web-portal to send a COA in my default port 3799 and after a little fix[1] on FreeRadius I can pass/proxy the packet to the other port (In this case, the appliance listening to acct,coa and auth in 1812) It will be possible to override the destination port. This solves my whole saga! :) [1] https://github.com/FreeRADIUS/freeradius-server/pull/1299 -- Jorge Pereira On Mon, Oct 5, 2015 at 5:21 AM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Sun, Oct 04, 2015 at 04:47:55PM -0300, Jorge Pereira wrote:
This sound bad... I will look for some other solution. btw, I believe
Very nasty hack, but you could always exec a script as part of authorize that calls radclient to send the coa and wait for a response. The script will need to make sure it times out quickly if it doens't receive an answer, and exec like this isn't very fast so if you've got a lot of auths/s then it'll bog the server down, but it should work.
Matthew
-- Matthew Newton, Ph.D. <mcn4@le.ac.uk>
Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (3)
-
Alan DeKok -
Jorge Pereira -
Matthew Newton