FR 3.0.12 exec_perl: ERROR: Failed to create pair &request:EAP-Message

Thor Spruyt thor.spruyt at
Sat Jun 3 13:21:50 CEST 2017

I'm not sure about an exact way to reproduce.
What I know is that it happens when there are multiple EAP-Message attributes in the request packet.
It appears that such large EAP-Message content is sent by the client after the server certificate has been received and when TLS 1.2 is used.
Here's an example:
        AVP: l=255 t=EAP-Message(79) Segment[1]
        AVP: l=255 t=EAP-Message(79) Segment[2]
        AVP: l=80 t=EAP-Message(79) Last Segment[3]
            EAP fragment
            Extensible Authentication Protocol
                Code: Response (2)
                Id: 6
                Length: 584
                Type: Protected EAP (EAP-PEAP) (25)
                EAP-TLS Flags: 0x80
                EAP-TLS Length: 574
                Secure Sockets Layer
                    TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange
                    TLSv1.2 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
                    TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages

Anyway, I'll check how 3.0.14 handles it...


----- Original Message -----
From: "Herwin Weststrate" <freeradius at>
To: "FreeRadius users mailing list" <freeradius-users at>
Sent: Saturday, June 3, 2017 9:29:25 AM
Subject: Re: FR 3.0.12 exec_perl: ERROR: Failed to create pair &request:EAP-Message

Thor Spruyt wrote:
> Hi,
> I have a problem with FR 3.0.12 as a proxy with a perl modules in the
> authorize section which does not include the EAP-Message attributes
> from the incoming request into the outgoing proxy request. When I
> disable the perl module, the EAP-Message is proxied correctly and the
> problem only occurs with multiple EAP-Message attributes.
> I found this conversation from 11/2016 which seems to be related:
>  However, the conversation seems to have stopped without a solution
> or fix and I don't see anything in the release notes of 3.0.13 or
> 3.0.14 either... so I guess the issue has not been taken care of
> yet.

I remember trying to reproduce that case without success. Even though, 
could you still try it with 3.0.14, not every fix ends up in the 
changelog or a mail thread.

Otherwise, since this problem occurs something in the conversion of 
binary data to a hexadecimal representation, I guess we could fix it by 
skipping that step. Perl can handle binary strings perfectly fine, and 
trying to make changes to a binary value in rlm_perl now requires a pack 
and unpack. If we make it a config option that is disabled by default, 
but enabled in the default cofig, all existing setups won't have 
behaviour changes when upgrading

Herwin Weststrate
List info/subscribe/unsubscribe? See

More information about the Freeradius-Users mailing list