We're setting up our APs to authenticate through RADIUS with our AD. We are able to connect fine with our PCs and iPhones, but there seems to be an issue with the Android phones authenticating. They stay on "Obtaining IP address". This is also a problem when using a PPSK with the Android phones.
On 802.1x, you would need to run debugs to see if they're completing negotiation and getting 'access-accept' from the AD/radius. Do the Android phones have problems with a really long wpa-psk key or just the ppsk?
We ran a packet capture, and there are Discovers but no Offers. After more testing, some of the iPhones are experiencing this issue as well.
So the dhcp-server is seeing the broadcasts and not answering up? The service is running? The available addresses are adequate in number for the WLAN? You are tracing at the dhcp-server or before that, i.e. are the requests getting to the server? Is the dhcp-server working ok for other scopes? Have you tried using the default gateway as a dhcp-server if it supports and enlarging the scope? It sounds extremely fishy that a dhcp server would not answer iphone or Android requests but respond to others but could the requests somehow be mangled or non-rfc-compliant?
Tracing from a PC on a distribution switch before the server. We created a test VLAN with it's own subnet to have the entire scope to work with (in case it was an address depletion issue). We haven't tried using the default gateway as the DHCP server. Also, it is affecting our windows laptops as well. There doesn't seem to be a pattern as to which types of devices are affected.
Is the dhcp server on the same subnet or are you using an ip helper address? If you put dhcp server on the same subnet such as the gateway does it work? Bottom line, if the traffic is leaving the Aerohive and there is no response from the dhcp server, the problem is not in Aerohive.