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

[Thor Spruyt]

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...

Thor

----- Original Message -----
From: "Herwin Weststrate" <freeradius at herwinw.nl>
To: "FreeRadius users mailing list" <freeradius-users at lists.freeradius.org>
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:
> http://freeradius.1045715.n5.nabble.com/PERL-and-EAL-TLS-Modul-gt-Failed-to-create-pair-amp-request-EAP-Message-RAD-REQUEST-EAP-Message-td5743281.html
>  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 http://www.freeradius.org/list/users.html