Let-me try to explain better my problem ... Here goes two message lists I've seen authenticating users:
####################### EAP-TTLS (SecureW2 V2.1.0) with PAP rad_recv: Access-Request packet from host 10.2.64.101:21645, id=35, length=214 Sending Access-Challenge of id 35 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=36, length=206 Sending Access-Challenge of id 36 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=37, length=260 Sending Access-Challenge of id 37 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=38, length=206 Sending Access-Challenge of id 38 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=39, length=206 Sending Access-Challenge of id 39 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=40, length=530 Sending Access-Challenge of id 40 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=41, length=295 Sending Access-Accept of id 41 to 10.2.64.101:21645 <-- Only this message contains the attributes returned from Inner auth. ####################### EAP-PEAP with MSCHAPv2 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=47, length=212 Sending Access-Challenge of id 47 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=48, length=311 Sending Access-Challenge of id 48 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=49, length=205 Sending Access-Challenge of id 49 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=50, length=205 Sending Access-Challenge of id 50 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=51, length=521 Sending Access-Challenge of id 51 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=52, length=205 Sending Access-Challenge of id 52 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=53, length=253 Sending Access-Challenge of id 53 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=54, length=307 Sending Access-Challenge of id 54 to 10.2.64.101:21645 rad_recv: Access-Request packet from host 10.2.64.101:21645, id=55, length=228 Sending Access-Challenge of id 55 to 10.2.64.101:21645 <-- Only this message contains the attributes returned from Inner auth. rad_recv: Access-Request packet from host 10.2.64.101:21645, id=56, length=237 Sending Access-Accept of id 56 to 10.2.64.101:21645 If I return the VLAN attributes based in the Inner identity, PEAP users only get the correct VLAN from time ... (most of the times they stay in the default VLAN assigned to the SSID), probably because the last message received by the AccessPoint doesn't carry VLAN attributes. If I return the VLAN attributes based in the Outer identity, because the Outer user is most of the times "[EMAIL PROTECTED]" I can't find the correct VLAN for the user and I'm vulnerable to "identity spoofing" if users send a valid Outer identity belonging to someone else with different VLAN. TIA. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
