freeradius and google protocol buffers.
Good day, community. 1. I need to organize interaction of freeradius with java-based backend, running as web service. So, I wrote small module, which packed received radius packet into google protocol buffer message and submit one to web service via persistent http connection: https://github.com/rssh/rlm_protobuf Interaction is done via next 'idl': https://github.com/rssh/rlm_protobuf/blob/master/src/vsa.proto freeradius give to service request_reply, then return with allow_reply_request set of actions, which we do need with pairs (add new one or remove or change) I want submit this module to freeradius, when It will be mature, but not sure: will one be generally useful and are you will be happy with 2 new optional dependencies (curl and protobuf-c) [?]. If yes -- I will start submit path requests after achieving working state. (now I assured that requests flow works, but yet not test all possible issues with authorization and service restart) 2. Yet one question for community -- it's about how people prefer to see representation of radius attributes in protocol buffers IDL. In present 'zero' version all nontrivial attributes are stored as array of bytes. In my task this is enough, but potentially such choice can cause issues with byte ordering, so may be better to create special message types for each type of attribute. So, I will be happy to see community opinion: (especially for #define PW_TYPE_ETHERNET and PW_TYPE_IFID) At last, I will be glad to see any feedback about this idea and thanks for great software. Regards !
Ruslan Shevchenko wrote:
1. I need to organize interaction of freeradius with java-based backend, running as web service. So, I wrote small module, which packed received radius packet into google protocol buffer message and submit one to web service via persistent http connection: https://github.com/rssh/rlm_protobuf
It looks interesting.
I want submit this module to freeradius, when It will be mature, but not sure: will one be generally useful and are you will be happy with 2 new optional dependencies (curl and protobuf-c) [?]. If yes -- I will start submit path requests after achieving working state. (now I assured that requests flow works, but yet not test all possible issues with authorization and service restart)
For submitting it back, fork the main "freeradius-server" repository, add your code, and send an email.
2. Yet one question for community -- it's about how people prefer to see representation of radius attributes in protocol buffers IDL. In present 'zero' version all nontrivial attributes are stored as array of bytes. In my task this is enough, but potentially such choice can cause issues with byte ordering, so may be better to create special message types for each type of attribute. So, I will be happy to see community opinion: (especially for #define PW_TYPE_ETHERNET and PW_TYPE_IFID)
Encoding each attribute as an independent message would be best.
At last, I will be glad to see any feedback about this idea and thanks for great software.
If the module works, use it. Alan DeKok.
On Tue, Nov 1, 2011 at 4:56 PM, Alan DeKok <aland@deployingradius.com> wrote:
Ruslan Shevchenko wrote:
1. I need to organize interaction of freeradius with java-based backend, running as web service. So, I wrote small module, which packed received radius packet into google protocol buffer message and submit one to web service via persistent http connection: https://github.com/rssh/rlm_protobuf
It looks interesting.
I want submit this module to freeradius, when It will be mature, but not sure: will one be generally useful and are you will be happy with 2 new optional dependencies (curl and protobuf-c) [?]. If yes -- I will start submit path requests after achieving working state. (now I assured that requests flow works, but yet not test all possible issues with authorization and service restart)
For submitting it back, fork the main "freeradius-server" repository, add your code, and send an email.
Just submit pull request with next commit: https://github.com/rssh/freeradius-server/commit/310873be275e3b77fc6e8d7da39...
2. Yet one question for community -- it's about how people prefer to see representation of radius attributes in protocol buffers IDL. In present 'zero' version all nontrivial attributes are stored as array of bytes. In my task this is enough, but potentially such choice can cause issues with byte ordering, so may be better to create special message types for each type of attribute. So, I will be happy to see community opinion: (especially for #define PW_TYPE_ETHERNET and PW_TYPE_IFID)
Encoding each attribute as an independent message would be best.
Ok, I have rewrote vsa.proto IDL in such style.
At last, I will be glad to see any feedback about this idea and thanks for great software.
If the module works, use it.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
participants (2)
-
Alan DeKok -
Ruslan Shevchenko