Problem solved! It was a routing problem... the APs are on a different subnet as the RADIUS server. Their default gateways were set to the correct host, that's why they could talk to the RADIUS server. The problem is, that recently we added a ppp connection to the server, which overwrote the default route, that way rendering the APs invisible... adding a route entry to the routing table solved the problem.<br>
<br>Thank you for your help, anyways.<br><br>Regards<br>Gergely Kiss<br><br><div class="gmail_quote">2009/6/16 kissg <span dir="ltr"><<a href="mailto:mail.gery@gmail.com">mail.gery@gmail.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It's getting even more interesting: using the same configuration, but with another access point (same model and firmware version): works flawlessly.<br>There are only two differences between the setups:<br>- In the test environment, the AP is located near to the test machine (it was placed about 5-6 meters from the AP, no walls between)<br>

- We didn't configure VLANs on the test AP.<br><br>I have a feeling, that the AP refuses the connection, because some kind of privilege checking fails (the client is not privileged to access the required VLAN). Does FreeRADIUS configuration need anything special, if the AP is configured for multiple VLANs?<br>

<br>The VLAN configuration looks like this in the live environment:<br><br>VLAN4 - Private vlan, the radius server is located here and an EAP-protected SSID is mapped to this VLAN<br>VLAN5 - Public vlan, mapped to an open SSID<br>

VLAN6 - Management vlan - untagged - we configure the APs using this VLAN<br><br>Probably the LDAP server has to provide some extra attribute which grants access to VLAN4, but I'm not sure. Could you please help?<br>
<br>
Thank you<br><br>Gergely Kiss</blockquote></div><br>