On Thu, Oct 24, 2019 at 10:18:34AM -0700, Heng Liu wrote: > In order to allow open source APs using linux/openwrt to support this, > we'd like to look into contributing patches to hostapd to add native > RadSec support over the next few months. > > Are you open to add native RadSec support to hostapd please? This is > probably a compile time flag (similar to the IPv6 support) to control > whether the RadSec support is compiled into the binary. If the feature > is compiled in, a new option (such as radsec_port) will trigger using > radsec instead of udp radius. We are planning to support both > access/accounting requests and dynamic auth requests (CoA/DM). Sure. RadSec has been on my long term to-do list for a long time, but there has just not been enough justification to find time to implement it so far. It might be more convenient to continue using auth_server_port configuration parameter for specifying both the transport and port instead of introducing a new parameter for this. For example, auth_server_port=radsec@2083, auth_server_port=udp@1812, with the "udp@" part being the default if no transport mechanism is explicitly specified. This should be much more convenient to add now that the eloop mechanisms work fine with TCP sockets and the TLS library wrapper functions can be used pretty easily with TCP+TLS cases like the HTTPS example client (tests/test-https.c) show. Those were missing when I initially considered RadSec support and it looked like a significant amount of work at the time, but hopefully not anymore. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
