Michael Richardson wrote:

On the topic of radiusclient: I've updated ServPOET from a really old version of radiusclient (one prior to freeradius!), to the latest git tree, and I've updated the client with some IPv6 TLV needs. I will issue a pull request soonish.

Thanks.

DTLS support for radiusclient would be a good thing to do; I wonder how small it can be made... I'm thinking that using raw public support in DTLS along with TOFU would be a really simple way to bootstrap (the admin would have to lock down the keys using a "mv" operation...)

The radiusclient code is pretty bad, TBH. I don't think I'd want to add OpenSSL support to it. We've done that in the server, and it's a lot of work. TBH, for embedded systems, I would recommend radsecproxy for all SSL work. It's simple, small, and supported.

btw, I really dislike having to carry all the dictionary files into an appliance system, and worse, parsing the files in each of the 6000 pppd's that runs. I'm thinking of a preparse dictionaries to .c data structure mechanism... what do you think?

I have some code to do that. But doing that involves major changes to radiusclient, which I'm not inclined to do.

It seems that client systems that link radiusclient *know* what TLVs they can deal with, the admin can not really add any new ones unless there is a scripting system on the client system.

Yes. Embedded systems should have their "known" attributes hard-coded. Any other attributes are by definition unknown, and therefore unimportant. Alan DeKok.