Identity PSK VLAN assignment bug on MR42 30.7?

[yaypingworks]

We use iPSK with group policies assigned to specific VLANs for our various wireless devices. Today I saw that at two locations devices that were supposed to be a part of VLAN 200 were actually assigned to VLAN 300, even though they still had the IP for VLAN 200 subnet (using DHCP) ... 

VLAN 300 is the native vlan trunk port that the APs connect to, why it put devices in that VLAN i dont know. Trying to connect to the SSID on a new device would fail saying 'cant connect to this network'

I had to end up rebuilding the SSID and then things started working and getting the correct VLAN assignment. Its like that specific SSID setup just broke.

Has anyone experienced this issue?

[GIdenJoe]

With or without radius?

If it is with you could also double check if the correct result had been passed to the AP.
If it is without have you checked if this behavior is on all the AP's?  In normal iPSK the bruteforcing of the keys is done on the AP's themselves so that means they have the list downloaded.  If that list would have been partially corrupted after an updated it could explain why the gpo assignment was incorrect and by rebuilding it the AP's redownloaded the list?

And no, I have 2 customers who use this solution and we didn't notice anything yet... 😜

[PhilipDAth]

In the earlier days of iPSK without RADIUS I used to have to reboot the APs from time to time.  I presume it was a problem with the downloaded list like @GIdenJoe mentioned.

It has been rock solid reliable for a long time now.

I would try giving an affected AP a reboot and see if it makes any difference.