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@herwinw.nl> To: "FreeRadius users mailing list" <freeradius-users@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-... 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