It's a limitation of HTTP/1.1. You need a connection for each HTTP request in flight. The rlm_rest module in v4 supports HTTP/2.0, so it can multiplex (run multiple requests over the same TCP connection simultaneously). The v4 module is also fully asynchronous, and uses a slab allocator for handles to minimise runtime memory allocations. It's about as good as it gets for a libcurl based implementation. On the commercial side (InkBridge), we've also integrated Netbox to do static IP assignment for our LDAP subscriber management API, it's very nice :) -Arran

On 10 Mar 2025, at 13:12, Brian Julin <BJulin@clarku.edu> wrote:

Michael Schwartzkopff wrote:

...

I jusst published a blog article how to use netbox as a backend for FreeRADIUS to lookup MAC addresses for MAC-bypass. It is a nice exercise of the use of the rest module of FreeRADIUS.

Nice... yes netbox is a pretty easy REST target. I'd encourage a test environment with it though as the netbox devs like to... change stuff... a lot.

Also, last time I looked at rlm_rest I was a bit concerned about the number of connections it seems to want to keep running. Maybe overly so... there isn't much of a guide about whether every thread really needs a connection or whatnot. Consolidated all transactions into an SQL database to eliminate races and batched them up from a single-connection REST script instead.

A linux box running netbox won't be bothered very much by this but with some appliances there's a pretty low limit on the number of REST connections allowed, so if you have a lot of services/servers trying to hit something over REST any extra connections can add up fast.

Maybe I misunderstand the way REST uses connections or maybe FR4 has improvements in sharing live connections between threads.

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

Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

On 10.03.25 20:12, Brian Julin wrote:

Michael Schwartzkopff wrote:

...

I jusst published a blog article how to use netbox as a backend for FreeRADIUS to lookup MAC addresses for MAC-bypass. It is a nice exercise of the use of the rest module of FreeRADIUS. Nice... yes netbox is a pretty easy REST target. I'd encourage a test environment with it though as the netbox devs like to... change stuff... a lot.

Also, last time I looked at rlm_rest I was a bit concerned about the number of connections it seems to want to keep running. Maybe overly so... there isn't much of a guide about whether every thread really needs a connection or whatnot. Consolidated all transactions into an SQL database to eliminate races and batched them up from a single-connection REST script instead.

A linux box running netbox won't be bothered very much by this but with some appliances there's a pretty low limit on the number of REST connections allowed, so if you have a lot of services/servers trying to hit something over REST any extra connections can add up fast.

Maybe I misunderstand the way REST uses connections or maybe FR4 has improvements in sharing live connections between threads.

Good points. I never thought this to be productive. It is more like a finger exercise to play with the rest module. The biggest  problem, besides the connection limitations, is the availability of the netbox. If netbox is down, all clients cannot access the network any more. You would have to set up a redundant netbox. So dumping the MAC address information into a database is the way to go in a productive environment. Michael.