My problem is something hindering the UDP packet flow communication between 192.168.2.1 (freeradius) and 192.168.2.43 (AC). I am writing to the list in the hope that someone has already dealt with same equipment and possibly run into the same problem.
The only time i've hit something remotely like that has been with EAP-TLS where the AP was dropping packets coming back from the STA because they were too large.
Any help and/or attention to my situation would be highly appreciated. How could I for example debug the traffic flow regarding AAA on the AC? Am I facing some trivial timeout issues or what is actually causing this hindrance? Is EAPOL taking place in the CAPWAP tunnel if the VAP is configured to do tunnel forwarding mode?
Usually it will be. If the AP is using CAPWAP it's probably too dumb to talk to a RADIUS server directly. You can check that fairly easily by looking at the SRC IP in the RADIUS packets. If it's your controller, then EAPOL is going via CAPWAP. No vendors that I know of terminate the 802.1X traffic on the AP, then proxy RADIUS packets via the AC (Access controller?).
What do I have to configure in order to establish some traffic priority for the communication between AC and FR (both EAPOL and UDP traffic)? I've been struggling with this issue for almost 1 month now, and I really am in desperate need of someone familiar with my operating environment. Thanks for your time and attention. MacGherl60
For reproducibility i'd setup a Linux device with wpa_supplicant. sync the wpa_supplicant and the AAA server to the same NTP server. Run a tcpdump on wpa_supplicant and the AAA server. Check for dropped packets and abnormal latency. Use eapol_test from the same subnet as the AC to check for issues related to network weather. Prove the issue is what you think it is first before attempting to fix it. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2