rc_aaa(3)
πΈ rc_aaa β the Radius client library page, but make it cute πΈ
okay bestie, this is the rc_aaa(3) page from the Radius client library. yeah. that's the whole NAME section. it's giving mysterious, it's giving "no notes", and we're moving on. π
β¨ SYNOPSIS β¨
#include <radcli/radcli.h>
int rc_aaa(
rc_handle *rh,
uint32_t client_port,
VALUE_PAIR *send,
VALUE_PAIR **received,
char *msg,
int add_nas_port,
rc_standard_codes request_type
);
π DESCRIPTION π
so what this does is: it builds an authentication/accounting request for the port id nas_port, using the value_pairs in send, and then it submits that whole thing to a server. like, it's the moment. it does the building and the sending. no cap. β¨
π PARAMETERS π
rhβ a handle to your parsed configuration. your whole setup lives in here, bestie.client_portβ
literally no description in the original. it's just sitting there. icon behavior, honestly. π
sendβ aVALUE_PAIRarray of values (e.g.,PW_USER_NAME). this is the stuff you're sending out into the world. π¦receivedβ an allocated array of received values. this is where the server's reply lands. π«Άmsgβ must be an array ofPW_MAX_MSG_SIZEorNULL; it will contain the concatenation of anyPW_REPLY_MESSAGEreceived. so if the server sent you a little note, it gets stitched together in here. πadd_nas_portβ this should be zero; if it's non-zero it will includePW_NAS_PORTin the sent pairs. so like... leave it at zero unless you know what you're doing, bestie. πrequest_typeβ one of the standard RADIUS codes (e.g.,PW_ACCESS_REQUEST). pick your fighter. π
π§ STRUCTURES π§
β οΈ Avoid using this structure directly. Use the rc_avpair_get_ functions. for real, don't touch it directly. i'm serious. π€
struct rc_value_pair {
char name[RC_NAME_LENGTH+1]; // attribute name if known.
uint64_t attribute; // attribute numeric value of type rc_attr_id including vendor; use VENDOR() and ATTRID() to separate.
rc_attr_type type; // attribute type.
uint32_t lvalue; // attribute value if type is PW_TYPE_INTEGER, PW_TYPE_DATE or PW_TYPE_IPADDR.
char strvalue[AUTH_STRING_LEN+1]; // contains attribute value in other cases.
struct rc_value_pair *next;
char pad[32]; // unused pad
};
and yes, it appears a second time. the original does that. i don't make the rules, i just deliver them with flair. π
β οΈ Avoid using this structure directly. Use the rc_avpair_get_ functions.
struct rc_value_pair {
char name[RC_NAME_LENGTH+1]; // attribute name if known.
uint64_t attribute; // attribute numeric value of type rc_attr_id including vendor; use VENDOR() and ATTRID() to separate.
rc_attr_type type; // attribute type.
uint32_t lvalue; // attribute value if type is PW_TYPE_INTEGER, PW_TYPE_DATE or PW_TYPE_IPADDR.
char strvalue[AUTH_STRING_LEN+1]; // contains attribute value in other cases.
struct rc_value_pair *next;
char pad[32]; // unused pad
};
π RETURN VALUE π
here's the vibe check on what comes back:
- the received value_pairs land in
receivedπ - messages from the server land in
msgπ - and the return value is:
OK_RC(0) on success β¨CHALLENGE_RC(3) on Access-Challenge received π- negative on failure π
π SEE ALSO π
okay this is the group chat, it's a long one, hold on. radcli.h(3), rc_aaa(3), rc_aaa_ctx(3), rc_aaa_ctx_free(3), rc_aaa_ctx_get_secret(3), rc_aaa_ctx_get_vector(3), rc_aaa_ctx_server(3), rc_acct(3), rc_acct_proxy(3), rc_add_config(3), rc_apply_config(3), rc_auth(3), rc_auth_proxy(3), rc_avpair_add(3), rc_avpair_assign(3), rc_avpair_copy(3), rc_avpair_free(3), rc_avpair_gen(3), rc_avpair_get(3), rc_avpair_get_attr(3), rc_avpair_get_in6(3), rc_avpair_get_raw(3), rc_avpair_get_uint32(3), rc_avpair_insert(3), rc_avpair_log(3), rc_avpair_new(3), rc_avpair_next(3), rc_avpair_parse(3), rc_avpair_remove(3), rc_avpair_tostr(3), rc_buildreq(3), rc_check(3), rc_check_tls(3), rc_conf_int(3), rc_conf_srv(3), rc_conf_str(3), rc_config_free(3), rc_config_init(3), rc_destroy(3), rc_dict_addattr(3), rc_dict_addval(3), rc_dict_addvend(3), rc_dict_findattr(3), rc_dict_findval(3), rc_dict_findvend(3), rc_dict_free(3), rc_dict_getattr(3), rc_dict_getval(3), rc_dict_getvend(3), rc_find_server_addr(3), rc_get_socket_type(3), rc_get_srcaddr(3), rc_getport(3), rc_mksid(3), rc_new(3), rc_openlog(3), rc_own_hostname(3), rc_read_config(3), rc_read_dictionary(3), rc_read_dictionary_from_buffer(3), rc_send_server(3), rc_setdebug(3), rc_test_config(3), rc_tls_fd(3)
that's the page, bestie. all of it. every last option and function name. we ate. π β¨
sign-off time: this one's from radcli, dated 2023-01-29, and it's page rc_aaa(3). mwah. ππ¦π
π¦ where this page comes from
- alpine 3.24: radcli-doc 1.4.0-r0 Β· BSD-2-Clause AND MIT
- epel 10: radcli-devel 1.5.2-3.el10_3 Β· BSD-2-Clause AND UMich-Merit AND HPND-Fenneberg-Livingston
- fedora 43: radcli-devel 1.4.0-5.fc43 Β· BSD-2-Clause AND UMich-Merit AND HPND-Fenneberg-Livingston
- fedora 43: radcli-devel 1.4.0-5.fc43 Β· BSD-2-Clause AND UMich-Merit AND HPND-Fenneberg-Livingston
- fedora 44: radcli-devel 1.4.0-6.fc44 Β· BSD-2-Clause AND UMich-Merit AND HPND-Fenneberg-Livingston
- fedora 44: radcli-devel 1.4.0-6.fc44 Β· BSD-2-Clause AND UMich-Merit AND HPND-Fenneberg-Livingston
- fedora 44: radcli-devel 1.5.2-3.fc44 Β· BSD-2-Clause AND UMich-Merit AND HPND-Fenneberg-Livingston
- fedora 44: radcli-devel 1.5.2-3.fc44 Β· BSD-2-Clause AND UMich-Merit AND HPND-Fenneberg-Livingston
- nixos 26.05: radcli 1.5.1
- nixpkgs unstable: radcli 1.5.2
- opensuse-leap 16.0: radcli-devel 1.4.0-bp160.1.11 Β· BSD-2-Clause AND MIT
- opensuse-leap 16.0: radcli-devel 1.4.0-bp160.1.11 Β· BSD-2-Clause AND MIT
- opensuse-leap 16.0: radcli-devel 1.4.0-bp160.1.11 Β· BSD-2-Clause AND MIT
- opensuse-leap 16.0: radcli-devel 1.4.0-bp160.1.11 Β· BSD-2-Clause AND MIT
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms