Thanks
Not sure what you are trying to save by not defining a dictionary. Tbh I'm just approaching to RADIUS, so not trying to save anything, apparently didn't know the proper way for this use case :D
and I guess that was what you wanted? More or less, the server starts and answers include the custom attribute:
(0) # Executing section post-auth from file /etc/raddb/sites-enabled/default (0) post-auth { (0) update { (0) reply::Foo := 0x483d342c20493d34 (0) } # update = noop (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) -> FALSE (0) update { (0) No attributes updated for RHS &session-state: (0) } # update = noop (0) } # post-auth = noop (0) Sent Access-Accept Id 0 from XXX:1812 to XXX:59903 length 53 (0) Foo := 0x483d342c20493d34 But the BMC on the other side does not consider it as valid, so it authenticates the user but without privileges (for reference https://www.supermicro.com/en/support/faqs/faq.php?faq=22374). If I manually define the user in the users file: testing Cleartext-Password := "password" Attr-26 = 0x483D342C20493D34 the answer is different (0) # Executing section post-auth from file /etc/raddb/sites-enabled/default (0) post-auth { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) { (0) if (session-state:User-Name && reply:User-Name && request:User-Name && (reply:User-Name == request:User-Name)) -> FALSE (0) update { (0) No attributes updated for RHS &session-state: (0) } # update = noop (0) [exec] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) if (EAP-Key-Name && &reply:EAP-Session-Id) { (0) if (EAP-Key-Name && &reply:EAP-Session-Id) -> FALSE (0) } # post-auth = noop (0) Sent Access-Accept Id 0 from XXX:1812 to XXX:58921 length 48 (0) Attr-26 = 0x483d342c20493d34 And the BMC authenticates the user with the correct privileges So I guess it's not exactly the same Francesco -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci@na.infn.it On 29/04/26 10:02, Bjørn Mork wrote:
Bjørn Mork via Freeradius-Users <freeradius-users@lists.freeradius.org> writes:
Francesco Di Nucci <francesco.dinucci@na.infn.it> writes:
Additional info - I also tried the same configuration on a more recent FreeRADIUS version (3.2.7 on Debian 13 instead of 3.0.27 on EL9), the error is the same
Francesco Di Nucci
On 28/04/26 18:18, Alan DeKok via Freeradius-Users wrote:
On Apr 24, 2026, at 8:17 AM, Francesco Di Nucci <francesco.dinucci@na.infn.it> wrote:
tried and reply:Attr-26 := 0x483D342C20493D34 /without quotes/ still returns Cannot parse RHS hex as the data type of the attribute Vendor-Specific.
Same for reply:Attr-26 := 0x1A1200002A7C483D342C20493D34 without quotes... Cannot parse RHS hex as the data type of the attribute Vendor-Specific
Not sure what you are trying to save by not defining a dictionary. Looks like FR insists on matching Attr-26 against the known dictionaries anyway.
I did a quick test with the Debian 13 package, adding to /etc/freeradius/3.0/dictionary (you will of course add this to a spearate file when done testing):
VENDOR SUPERMICRO 10876 format=1,0
BEGIN-VENDOR SUPERMICRO ATTRIBUTE Foo 72 octets END-VENDOR SUPERMICRO
Only then would FR accept something like this:
Attr-26 := 0x00002A7C483D342C20493D34
But it will only accept 0x48 (72) as the first byte of the value. Seems you have to define every possible first byte this way. There is no "format=0". But worst case, just create 256 dummy VSAs... Forget it. FR accepts the config, but it doesn't actually work. Trying to return that attribute results in
(1) ERROR: Failed sending reply: ERROR: Unknown attribute type 21
And type 21 is PW_TYPE_VSA if I'm not mistaken.
Rewriting to
Attr-26.10876.72 := 0x3D342C20493D34
makes it "work". But that's ugly. Anyway, with that I see these bytes returned from FR:
1a 0e 00 00 2a 7c 48 3d 34 2c 20 49 3d 34
and I guess that was what you wanted?
Bjørn