Monitor the number of open EAP sessions

Alan DeKok aland at
Thu Nov 23 15:26:51 UTC 2023

On Nov 23, 2023, at 10:01 AM, Sergey Marochkin < at> wrote:
>> There's no real way to get per-module statistics out of the server.
> However, we're looking into fixing that.  It's not completely trivial, due
> to a host of issues such as threading, etc.

  Yes.  If features are trivial, they usually go in quickly.  If a feature has been waiting for a long time, it's usually because the feature is hard.

> I would like to ask if you have found a way to fix this? Unfortunately, I
> periodically catch the previously described problem of overflow of open
> connections on the radius server, so I would like to be able to get
> statistics on them.

  It's not "open connections", it's "partially completed EAP sessions".

  Since you can't fix the supplicant, you can only fix the server.  The suggestions are:

* set timer_expire to a low value.

  Too low, and normal sessions will expire before they're finished.

  Too high, and the server will use a lot of ram for no purpose.

* set max_sessions to a high value

  It's just RAM.  It's cheaper than developer time.  Set it to maybe 10000,
  and the server will use another few megabytes of memory.  Monitor it and see.

  If there's still an issue (and you have more RAM), bump up the number a bit.

* edit rlm_eap to add a new configuration parameter:

	dedup_key = "%{Calling-Station-Id}"

  This will be a bit more work, but might help.  The idea is to track old sessions for the same Calling-Station-Id, and forcibly expire the old one when a new session comes in.

   For this to work, you'll have to:

* add it as a configuration in the CONF_PARSER

* add it to the rlm_eap configuration data structure

* if it's set, expand it when the EAP module starts a new session

* add a thread-safe rbtree to the EAP module instance

* look up the dedup_key in eap.c, just before the call to eap_handler_alloc()

  if there is an entry, delete it and the old handler.

  It's a bit of work, but likely not too bad.  Let me take a look.

  Alan DeKok.

More information about the Freeradius-Users mailing list