Fwd: Child is hung (max_request)

Alan DeKok aland at deployingradius.com
Mon Nov 24 16:26:41 CET 2014


Iliya Peregoudov wrote:
> There is nothing inherently sophisticated in the RADIUS protocol itself.
> Implementing a RADIUS-to-Diameter translator is not inherently harder
> than implementing anything-else-to-Diameter translator.

  The issue is less that, than other topics.  If you have to ask "How do
I write a daemon in C", the answer is "it takes a long time".

  Doing a *basic* implementation of something is easy.  Doing a *robust*
implementation is much harder.

> Topic starter has already implemented something-else-to-Diameter
> translator as a standalone process. To integrate it with RADIUS he has
> to implement RADIUS-to-something-else translator as a freeradius module,
> and this module does not work well.

  We're working in separating out the RADIUS portions from FreeRADIUS.
e.g. it already does VMPS and DHCP.  Adding full Diameter support is in
progress.

> The problem with freeradius is that it was not designed to be used as
> extensible protocol translator. One cannot write a freeradius module
> that will translate RADIUS to any other protocol in non-blocking manner
> because freeradius module interface is blocking. So mentioned earlier
> freeradius module *can not* work well.

  Yes.  The modules are *intended* to be blocking.  And will *always* be
blocking.  The modules are protocol-agnostic interfaces to databases.
Any other design is wrong, for a host of reasons.

   Protocol translation / proxying is something which belongs somewhere
else.  In v3, there are new "proto_dhcp" plugins, which have an API
different from the module API.  The result is that those plugins can
implement protocols.

  Alan DeKok.


More information about the Freeradius-Users mailing list