On Wed, Aug 8, 2012 at 3:43 PM, stefan novak <lms.brubaker@gmail.com> wrote:
If it's "sometimes", then it would be wise to compare the debug log of when the client succeeds and when it does not. Also, IIRC RHEL5 has 2.1.12 already, so you should upgrade just in case this is a fixed bug.
just updated my testserver to 2.1.12. I test now with rad_eap_test utility to eliminate a client failure. the behaviour gets more stranger. the test utility also fails sometimes,
How did you determine that it fails?
[root@wlan-radius rad_eap_test-0.23]# ./rad_eap_test -H 172.21.15.1 -P 1812 -S testtest -u nagios -p xxxx -m WPA-EAP -e PEAP -2 MSCHAPV2 access-accept; 0 [root@wlan-radius rad_eap_test-0.23]# ./rad_eap_test -H 172.21.15.1 -P 1812 -S testtest -u nagios -p xxxx -m WPA-EAP -e PEAP -2 MSCHAPV2 access-accept; 0 [root@wlan-radius rad_eap_test-0.23]# ./rad_eap_test -H 172.21.15.1 -P 1812 -S testtest -u nagios -p xxxx -m WPA-EAP -e PEAP -2 MSCHAPV2 access-accept; 0 [root@wlan-radius rad_eap_test-0.23]# ./rad_eap_test -H 172.21.15.1 -P 1812 -S testtest -u nagios -p xxxx -m WPA-EAP -e PEAP -2 MSCHAPV2 access-accept; 0 [root@wlan-radius rad_eap_test-0.23]# ./rad_eap_test -H 172.21.15.1 -P 1812 -S testtest -u nagios -p xxxx -m WPA-EAP -e PEAP -2 MSCHAPV2 access-accept; 1
Those are all access-accept, aren't they? The second number (reading from http://wiki.eduroam.cz/rad_eap_test/README) should be latency, not an indication that something failed. CMIIW. -- Fajar