Re: External trigger for CoA

classic Classic list List threaded Threaded
2 messages Options
| Threaded
Open this post in threaded view
|

Re: External trigger for CoA

Users mailing list
Hi

I have been able to implement this approach with coa-relay and it mostly working, but there are a couple of issues with that.

Here are my observations (note I am talking about FR 3.0.x branch):

1) We may specify Packet-DST-IP-Address/Packet-Dst-IPv6-Address or Home-Server-Pool to be able to forward CoA request to the particular NAS.

2) If Packet-DST-IP-Address is specified then FR searches the home_server by port type UDP and this is hardcoded. Of course, if I have configured the home_server with RADSEC/TCP FR cannot find it. But at this step that would not be such a big issue if I would be able to specify the NAS via Home-Server-Pool.

3) If Home-Server-Pool is used, FR still cannot find the home_server. Moreover, it is crashed with SIGSEGV. The reason for this is:

        a) listener is set to null in request_coa_originate in process.c
           coa->listener = NULL; /* copied here by request_alloc_fake(), but not needed */
           here is the git ref: https://github.com/FreeRADIUS/freeradius-server/commit/d9dd706503897a4c271b0424221d651115fab446


        b) listener type is checked in home_server_ldb in realms.c

                if ((request->listener->type == RAD_LISTEN_DETAIL) &&
                    (request->packet->code == PW_CODE_ACCOUNTING_REQUEST) &&
                    (fr_ipaddr_cmp(&home->ipaddr, &request->packet->src_ipaddr) == 0)) {
                        continue;
                }
           Here the listener is NULL and hence the SIGSEGV.



Once I deleted the "coa->listener = NULL;" The flow started to be working as expected.

Also, if I check if the listener is NULL before checking its type in home_server_ldb - that also worked.


The questions are:

        1) May you recall the reason for "coa->listener = NULL;" in request_coa_originate?
        2) Is it safe to remove that line, essentially to revert the commit referenced above?
        3) Alternatively, will that be better to check for the listener is NULL just to avoid the crash in home_server_ldb?


Thanks,
Vadim

_____________________________________
Sent from http://freeradius.1045715.n5.nabble.com

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: External trigger for CoA

Alan DeKok-2
On Sep 27, 2020, at 1:34 AM, Vadim via Freeradius-Users <[hidden email]> wrote:
> I have been able to implement this approach with coa-relay and it mostly working, but there are a couple of issues with that.

  That's good.

> Here are my observations (note I am talking about FR 3.0.x branch):
>
> 1) We may specify Packet-DST-IP-Address/Packet-Dst-IPv6-Address or Home-Server-Pool to be able to forward CoA request to the particular NAS.
>
> 2) If Packet-DST-IP-Address is specified then FR searches the home_server by port type UDP and this is hardcoded. Of course, if I have configured the home_server with RADSEC/TCP FR cannot find it. But at this step that would not be such a big issue if I would be able to specify the NAS via Home-Server-Pool.

  Yeah, that should be configurable.  But you can also use Home-Server-Name = "name" to avoid IP / port / protocol issues.

> 3) If Home-Server-Pool is used, FR still cannot find the home_server. Moreover, it is crashed with SIGSEGV. The reason for this is:
>
> a) listener is set to null in request_coa_originate in process.c
>   coa->listener = NULL; /* copied here by request_alloc_fake(), but not needed */
>   here is the git ref: https://github.com/FreeRADIUS/freeradius-server/commit/d9dd706503897a4c271b0424221d651115fab446
>
>
> b) listener type is checked in home_server_ldb in realms.c
>
>                if ((request->listener->type == RAD_LISTEN_DETAIL) &&
>                    (request->packet->code == PW_CODE_ACCOUNTING_REQUEST) &&
>                    (fr_ipaddr_cmp(&home->ipaddr, &request->packet->src_ipaddr) == 0)) {
>                        continue;
>                }
>   Here the listener is NULL and hence the SIGSEGV.

  That's wrong.

> Once I deleted the "coa->listener = NULL;" The flow started to be working as expected.
>
> Also, if I check if the listener is NULL before checking its type in home_server_ldb - that also worked.
>
>
> The questions are:
>
> 1) May you recall the reason for "coa->listener = NULL;" in request_coa_originate?

  I don't recall exactly, but it's the correct thing to do.  The CoA packet wasn't received from a socket, so it shouldn't have a listener.

> 2) Is it safe to remove that line, essentially to revert the commit referenced above?
> 3) Alternatively, will that be better to check for the listener is NULL just to avoid the crash in home_server_ldb?

  I pushed a fix in home_server_ldb().

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html