home_server type = auth+acct+coa in the same port?
Hi, somebody know if is possible to have a 'home_server' type of auth+acct+*coa *(same port)? -- Jorge Pereira
Alan, The reason of my question is because the product RedBack (Nokia) has this capability. And i found in the latest release notes from 3.0.5 the below point. - CoA and Disconnect packets can now be sent to a specific home server by setting control:Packet-Dst-IP-Address and (optionally) control:Packet-Dst-Port. I really would like to have this and I intend to add this support. what do you think about that? -- Jorge Pereira On Fri, May 8, 2015 at 11:51 AM, Alan DeKok <aland@deployingradius.com> wrote:
On May 8, 2015, at 10:31 AM, Jorge Pereira <jpereiran@gmail.com> wrote:
somebody know if is possible to have a 'home_server' type of auth+acct+*coa *(same port)?
It's not possible.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 8, 2015, at 11:08 AM, Jorge Pereira <jpereiran@gmail.com> wrote:
The reason of my question is because the product RedBack (Nokia) has this capability.
It is very much non-standard.
And i found in the latest release notes from 3.0.5 the below point.
- CoA and Disconnect packets can now be sent to a specific home server by setting control:Packet-Dst-IP-Address and (optionally) control:Packet-Dst-Port.
I really would like to have this and I intend to add this support. what do you think about that?
Sure. The main difficulty is in parsing the config, and verifying that the destination is, in fact, capable of handling the packet being sent. To be honest, the best solution would be to fix the config so that "type = auth+acct" is disallowed. Instead, just allow multiple "type" fields. And change the home_server definition to have an array of allowed types. This means it's easy to understand, easy to parse, and easy to extend in the future. And be sure that the changes are backwards compatible. :) Alan DeKok.
Alan, I guess that i got it your idea... because today we have the src/main/command.c that have a static 'options' like the string "auth+acct" (you can't invert the order!) that set a static defines. I think that we can change for bit-wise matchs... like: <pseudo imaginary code> for (t=types; t=parser_ninja_get("type"); t++) { if (t == "acct") type_value |= HOME_TYPE_ACCT; else if (t == "auth") type_value |= HOME_TYPE_AUTH; else if (t == "coa") type_value |= HOME_TYPE_COA ............. } // And in the places when need to match... if (type_value & HOME_TYPE_ACCT) do_handle_acct(); else if (type_value & HOME_TYPE_COA) do_handle_coa(); </pseudo imaginary code> something like that? btw... I have looked around, looks like a hard work! :) -- Jorge Pereira On Fri, May 8, 2015 at 12:14 PM, Alan DeKok <aland@deployingradius.com> wrote:
On May 8, 2015, at 11:08 AM, Jorge Pereira <jpereiran@gmail.com> wrote:
The reason of my question is because the product RedBack (Nokia) has this capability.
It is very much non-standard.
And i found in the latest release notes from 3.0.5 the below point.
- CoA and Disconnect packets can now be sent to a specific home server by setting control:Packet-Dst-IP-Address and (optionally) control:Packet-Dst-Port.
I really would like to have this and I intend to add this support. what do you think about that?
Sure. The main difficulty is in parsing the config, and verifying that the destination is, in fact, capable of handling the packet being sent.
To be honest, the best solution would be to fix the config so that "type = auth+acct" is disallowed. Instead, just allow multiple "type" fields. And change the home_server definition to have an array of allowed types.
This means it's easy to understand, easy to parse, and easy to extend in the future.
And be sure that the changes are backwards compatible. :)
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 8, 2015, at 11:30 AM, Jorge Pereira <jpereiran@gmail.com> wrote:
I guess that i got it your idea... because today we have the src/main/command.c that have a static 'options' like the string "auth+acct" (you can't invert the order!) that set a static defines.
In command.c, that string is used only when printing. So it's easy enough to fix.
I think that we can change for bit-wise matchs... like:
That's probably the best approach.
// And in the places when need to match...
if (type_value & HOME_TYPE_ACCT) do_handle_acct(); else if (type_value & HOME_TYPE_COA) do_handle_coa();
Yes. There's already code to do this for the auth+acct, I think.
</pseudo imaginary code>
something like that? btw... I have looked around, looks like a hard work! :)
It's just work. I don't think it involves serious changes to the core. Alan DeKok.
Alan, I have started this today, hope to finish soon. Btw, do you have suggestions about the targets on the Makefiles or scripts to test the server? Something that can be used to improve the tests! Em 08/05/2015 12:37, "Alan DeKok" <aland@deployingradius.com> escreveu:
On May 8, 2015, at 11:30 AM, Jorge Pereira <jpereiran@gmail.com> wrote:
I guess that i got it your idea... because today we have the src/main/command.c that have a static 'options' like the string "auth+acct" (you can't invert the order!) that set a static defines.
In command.c, that string is used only when printing. So it's easy enough to fix.
I think that we can change for bit-wise matchs... like:
That's probably the best approach.
// And in the places when need to match...
if (type_value & HOME_TYPE_ACCT) do_handle_acct(); else if (type_value & HOME_TYPE_COA) do_handle_coa();
Yes. There's already code to do this for the auth+acct, I think.
</pseudo imaginary code>
something like that? btw... I have looked around, looks like a hard work! :)
It's just work. I don't think it involves serious changes to the core.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On May 8, 2015, at 12:13 PM, Jorge Pereira <jpereiran@gmail.com> wrote:
I have started this today, hope to finish soon. Btw, do you have suggestions about the targets on the Makefiles or scripts to test the server? Something that can be used to improve the tests!
There aren't any tests which proxy packets. But it's possible to add tests that certain keywords are accepted (or not). Alan DeKok.
participants (2)
-
Alan DeKok -
Jorge Pereira