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. --E Em 14-Jul-17 10:29 AM, Alan DeKok escreveu:
On Jul 13, 2017, at 4:50 PM, Edelberto Franco <esilva@midiacom.uff.br> wrote:
Hi
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) FreeRadius 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 200.130.15.23: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 200.130.15.23:33001 to 0.0.0.0:2083 length 464 (2) User-Name = "eduroam@rnpteste.br" ... (2) EAP-Message = 0x0202013315001603010128010001240303d2f5eea4fdbe3d97827f69579ce66256228d2985dafcc71333fe57a0d62fe0610000aac030c02cc028c024c014c00a00a500a300a1009f006b006a0069006800390038003700360088008700860085c032c02ec02ac026c00fc005009d003d00350084c02fc0 (2) State = 0x161759b417154cb0f3b4952e04b41a4d ... (3) Received Access-Request Id 3 from 200.130.15.23:33001 to 0.0.0.0:2083 length 464 (3) User-Name = "eduroam@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 = 0x0202013315001603010128010001240303d2f5eea4fdbe3d97827f69579ce66256228d2985dafcc71333fe57a0d62fe0610000aac030c02cc028c024c014c00a00a500a300a1009f006b006a0069006800390038003700360088008700860085c032c02ec02ac026c00fc005009d003d00350084c02fc0 (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 output.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html