We are having issues across our enterprise network with a new Guest access that we have implemented.
Our topology looks like this.
Local AP's in a given building, Local controller in same building, and a 3200 Guest Controller in a DMZ for internet access.
The guest controller is acting as the DHCP server.
If we use a PC or laptop, we connect successfully 100% of the time. When we disable the session and re-establish the session, we are also successfull at reconnecting.
When we use any type of handheld device, Iphone, Blackberry, tablets etc, For the first attempt to connect to the Guest access, we are for the most part, successful.
If we turn off wifi and turn it back on, or reboot the handheld device, they cannot re-establish a DHCP address.
Our protocol analyzer team has captured traffic via sniffing inside the GRE tunnels and discovered the following:
When the handheld device attempts to re-establish a connection to Guest access, it does a "DHCP Discovery"
The Guest controller in the DMZ responds back with a "DHCP Offer", but it is responding to the handhelds original IP address that it had on the first successful session. However, the handheld does not have an IP address yet, it is trying to get one. So the local controller sends the unicast to the AP and the Offer never makes it to the handheld.
Should the Guest controller in the DMZ not send a DHCP Offer via a Broadcast to find the MAC address of the handheld rather than a unicast to the originalIP address?
When we sniff the same traffic but from a Laptop, who is attempting to re-establish a new connection, the Laptop sends a DHCP Request, and not a "DHCP Discovery", to the DMZ controller.
Whats funny here, is that the DMZ controller responds to with a "DHCP ACK" by sending a broadcast to find the MAC address of the machine.
I'm not certain if this can be fixed by some derivation rules, or options on the controller.
Looking for suggestions,
Thanks,
#3200