The documentation does not specify how vendor specific attributes are encoded/accessed. In Particular RFC2865 specifies a format for encoding multiple attributes by a single vendor in a single Attribute 26. I do not see how i would get those.

Please add support for
rfc6613 - RADIUS over TCP
rfc6614 - Transport Layer Security (TLS) Encryption for RADIUS

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

I am looking for a Radius lib for Rust and found this library and radius-rust.

Did a quick check of the supported features and API and I think I prefer radius-rs but a copyleft license is a no go for my project.

I also think the current license might prevent more contribution to your lib.

What is your view on changing to a more permissive license like MIT or Apache 2.0?

Thank you

Now it does the liner searching, this should not be effective.

One of the most common uses of RADIUS these days is for 802.1x authentication - EAP/RADIUS. RFC3748/RFC3579 requires "super-protocol" interaction in that EAP is embedded within RADIUS and the EAP protocol interactions (init/challenge/response/result) occur within the RADIUS packets atop higher OSI layers than ethernet-level EAPOL transactions.
In order to be able to use this code as a proxy between wireless clients and RADIUS services which themselves do not support EAP, support for RFC3579 would be required in the library.
@moznion - any chance you might have the cycles to implement in the near term, or should i try to pollute your otherwise clean code with my garbage hackery to achieve basic functionality?
Thanks for writing this, neat implementation.

APVs like Tunnel-Type are added to a packet using the function from_tagged_u32, which does not take into account the appropriate length of the attribute. Something similar happens with Tunnel-Medium-Type.

As mentioned in RFC2868, the length for Tunnel-Type is always 6, and this mismatch can cause problems with clients that strictly follow this. radtest will show attributes that do not follow these standards as Attr-N instead of decoding it into the appropriate name, so this can be useful when trying to detect these issues.

ref: https://www.ietf.org/rfc/rfc6929.txt

There doesn't seem to be a way to retrieve a list of all AVPs from a Packet currently, just get AVPs with a specific AVPType via Packet::lookup and Packet::lookup_all. Is this intentional?

I see Packet's private attributes field is of type core::attributes::Attributes, which has visibility pub(crate) instead of just pub... so it seems like this might be intentional. If it is, could you provide some of the reasoning as to why? A blanket Packet::get_attributes method would be quite helpful for my use-case.

I'm using the library for radius load testing / pretty much just using the encode/decode functionality.

Right now there's no way to set the identifier of the packet to anything other then the rand value, which is a problem if you're sending multiple packets over the same socket.

I seem to have found a "bald spot" in the otherwise well-annotated and commented code: encode() and decode() in attributes.rs seem a bit sparse on why things are done the way that they are, and it does a fair deal of heavy lifting in the code. If you get a chance at some point, would be swell to have the ins and outs of that code clearly explained to us mortals 😄