Extensible Authentication Protocol support

[sempervictus]

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.

[moznion]

Thank you for your suggestion, @sempervictus. I totally agree with your inquiry and actually I intended to implement that feature at the releasing time of this library, but I don't use that function in my product so that has been postponed to implement. At the moment, I've not implemented that feature but I recognize the demand, so I think now is the time to implement that.

[sempervictus]

Thanks a ton - i've a live test-case to work through debugging if that would be handy. Getting my head around how you have dictionaries working here. Takes a little bit of cross-file groking to make sense of it, but starting to get the hang. If you could throw up an R&D branch for the functionality, i'll happily test and collaborate off of it as you push to get hands dirty in the code without messing up the elegance of this implementation.

[sempervictus]

Looks like the term "string" is a bit loose in the spec

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |     String...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      79 for EAP-Message

because

pub const EAP_MESSAGE_TYPE: AVPType = 79;
/// Delete all of `eap_message` values from a packet.
pub fn delete_eap_message(packet: &mut Packet) {
    packet.delete(EAP_MESSAGE_TYPE);
}
/// Add `eap_message` value-defined integer value to a packet.
pub fn add_eap_message(packet: &mut Packet, value: String) {
    packet.add(AVP::from_string(EAP_MESSAGE_TYPE, &value));
}
/// Lookup a `eap_message` value-defined integer value from a packet.
///
/// It returns the first looked up value. If there is no associated value with `eap_message`, it returns `None`.
pub fn lookup_eap_message(packet: &Packet) -> Option<Result<String, AVPError>> {
    packet
        .lookup(EAP_MESSAGE_TYPE)
        .map(|v| Ok(v.encode_string()?))
}

used in

        let maybe_eap_message = rfc3579::lookup_eap_message(req_packet);
        match maybe_eap_message {
            Some(e) => match e {
                Ok(m) => info!("Found eap message:\n{}\n",m),
                Err(e) => error!("Could not decude eap message due to:\n\t{}\n",e)
            },
            None => info!("No eap message found")
        }

produces

[2022-07-27T23:11:24Z ERROR server] Could not decode eap message due to:
        decoding error: invalid utf-8 sequence of 1 bytes from index 1

any pointers on what i might be doing wrong here? :smile: Thanks

[sempervictus]

Getting the hang of this more or less - dictionary data feeds into code-gen, that produces the Rust rfcX files, and EAP-handling logic actually needs to go in there.