TLS communication, EAP does not work
esilva at midiacom.uff.br
Sat Jul 15 19:42:49 CEST 2017
Updating this thread*
Em 15-Jul-17 11:02 AM, Edelberto Franco escreveu:
> Updating this threat to our colleagues...
> Changing the parameter "fragment_size" in tls block on
> "sites-enable/tls" file, packets were sent and received by FR3 servers
> (using 756 - less than 1024).
> But it is not an absolute truth, sometimes packets are lost and authA
> not happens.
> *needing more investigation.
> Em 14-Jul-17 10:29 AM, Alan DeKok escreveu:
>> On Jul 13, 2017, at 4:50 PM, Edelberto Franco
>> <esilva at midiacom.uff.br> wrote:
>>> I'm working with Luciano on eduroam BR and trying to solve this.
>>> I attached our debug files.
>>> 4 files:
>>> 1) debug-eapol-from-ujfteste-to-rnpteste - the client eapol running
>>> an auth test
>>> 2) debug-ufjfteste-FR3 - FreeRadius @ inst1/ufjfteste.br
>>> 3) debug-rnpteste-FR3 - FreeRadius @ inst1/rnpteste.br
>>> 4) debug-radsecproxy-FLR - radsecproxy @ federation level
>> You don't say which server is doing what, or why. Is (1) sending
>> to (2) which is proxying to (3) and then (4)?
>> Describing the system would be helpful.
>>> What caught my attention was this "error" on the local (institution)
>>> rlm_eap (EAP): No EAP session matching state 0xc6ab1049c7a90598
>> There's some telling logs in mpteste:
>> (1) # Executing group from file /etc/freeradius/sites-enabled/default
>> (1) Sent Access-Challenge Id 1 from 0.0.0.0:2083 to
>> 18.104.22.168:33001 length 0
>> (1) EAP-Message = 0x010200061520
>> (1) Message-Authenticator = 0x00000000000000000000000000000000
>> (1) State = 0x161759b417154cb0f3b4952e04b41a4d
>> (1) Proxy-State = 0x31
>> (2) Received Access-Request Id 2 from 22.214.171.124:33001 to
>> 0.0.0.0:2083 length 464
>> (2) User-Name = "eduroam at rnpteste.br"
>> (2) EAP-Message =
>> (2) State = 0x161759b417154cb0f3b4952e04b41a4d
>> (3) Received Access-Request Id 3 from 126.96.36.199:33001 to
>> 0.0.0.0:2083 length 464
>> (3) User-Name = "eduroam at rnpteste.br"
>> (3) NAS-IP-Address = 127.0.0.1
>> (3) Calling-Station-Id = "02-00-00-00-00-01"
>> (3) Framed-MTU = 1400
>> (3) NAS-Port-Type = Wireless-802.11
>> (3) Service-Type = Framed-User
>> (3) Connect-Info = "CONNECT 11Mbps 802.11b"
>> (3) EAP-Message =
>> (3) State = 0x161759b417154cb0f3b4952e04b41a4d
>> (3) Message-Authenticator = 0x384c2741f7321ca2d8e8f78b9c0864b3
>> The server is sending a reply to packet 2, and then packet 3 is a
>> retransmit of packet 2. That's wrong. The client should go on to
>> the next packet.
>> This is confirmed from the eapol_test packet:
>> Attribute 24 (State) length=18
>> Value: 161759b417154cb0f3b4952e04b41a4d
>> Attribute 80 (Message-Authenticator) length=18
>> Value: 67ecbe0e885a25686f87da3397222a19
>> Next RADIUS client retransmit in 3 seconds
>> EAPOL: SUPP_BE entering state RECEIVE
>> EAPOL: startWhen --> 0
>> STA 02:00:00:00:00:01: Resending RADIUS message (id=2)
>> Packets are being lost somewhere. I have no idea where.
>> I suggest setting up a test system. And don't use radsecproxy.
>> The debug output is entirely useless. It doesn't show the packets
>> going back and forth, so it is of *zero* help for debugging.
>> Test the systems, and watch the packets going back and forth.
>> Then READ THE DEBUG OUTPUT. If it's complaining that there's no EAP
>> session for the State attribute... go back in the debug log looking
>> for other references to that State. See if the packets are being
>> retransmitted. See if the reply sent by the proxy is making it to
>> the client.
>> i.e. debug it. Trace the packets step by step through the
>> system. It isn't hard. It just takes some effort to read the debug
>> Alan DeKok.
>> List info/subscribe/unsubscribe? See
More information about the Freeradius-Users