We have 2 client VLANs available via wi-fi, each one with it's own SSID. One is an internal corporate VLAN, and the other is an external guest VLAN which connects directly to the internet. The APs themselves are setup as DHCP servers for the external network, and devices that only ever operate on the external VLAN always get thier DHCP address from the APs without issue.
Occasionally an internal corporate device needs to switch over to the external VLAN, and we often find that they don't pick up an IP address when doing so.
Running client monitor I can see the DHCP offers being sent from the AP, but running Wireshark on the client device it seems that the DHCP offer is never recieved. This only seems to be an issue when switching from the internal SSID to the external SSID - any ideas what could cause this behaviour?
We are facing a similar issue with DHCP offers not being received by the client.
Have you found a solution for your problem?
Just out of interest what client devices are you using? We're using Surface Pro 2 and Surface Pro 3 tablets (nothing else unfortunately so I can't compare results)
Also what APs are you using? Ours are mostly the AP130 model with the 6.5r1.2154 HiveOS, but I suspect that our AP120 and AP121 with 6.x OSes are in the same boat
The APs are AP120 with 6.2r1c.1943.
We've dumped the packages during an "ipconfig /renew" on an AP. We see the DHCP Discover from the client and also the DHCP offer from the DHCP-Server. But the client never gets this offer (no DHCP ACK)....
When we connect to notebook via a LAN cable, then suddenly also the Wifi Adapter gets an address via DHCP....
We have not yet tried disabling the wireless card and then re-enabling it. Will do that the next time the issue appears.
What usually helps is doing a deauth of the client on the access point and then restarting the client.
Then it gets an correct IP address.
Hi Tobias, just a bit of an update on what I've found so far. The issue in the original post (IP from DHCP server on the AP not received, when a client moves from the internal VLAN/SSID to the external VLAN) is not the same issue as in my 2nd post (IP from corporate DHCP not applied sometimes, for some clients on the internal VLAN)
The first issue was related to a DHCP offer from the AP not being received by the client, and it seems to have been resolved by enabling the 'DHCP relaly' function on all of the APs who aren't already DHCP servers themselves. This shouldn't have been necessary, because the DHCP offers should be heard by any client authenticated on the external network, given that all APs can connect to and service that VLAN. I asked the question in this thread https://getsatisfaction.com/aerohive/topics/dhcp-relay-function and another helpful member agreed. Nonetheless, enabling the relay function does seem to have resolved that particular issue so far
The 2nd issue might also be resolved (time will tell), but I found in that scenario the client was actually receiving the DHCP offer (after sending out a DHCP DISCOVER) but the client wasn't following up with a DHCP REQUEST after receiving the offer. One change I made was to correct the NTP settings on the APs, because I discovered that the clock was wrong on most of them. The issue didn't seem to be resolved at that point, even though I could verify that the AP clocks were all correct, but the following day the test client I was using started working. I'll keep an eye on the issue and see if it crops up again, but if not, the NTP change might have fixed it
I'm starting to think this may be a firmware issue because ever since I've updated my AP's Ive been getting this exact same issue. I even had engineers from Aerohive come take a look at it and we could not resolve it. In addition, when we analyzed our Pcap, Aerohive noticed that once the client sends out a DHCP request, the Server then sends it back but the AP distributes it to the wrong interface. It's driving me crazy because we can't seem to resolve anything with the issues we're having with Aerohive. When we fix one thing another issue comes up, and now that we resolved our old problems we now have this DHCP issue on the AP's. Furthermore, I like to mention that our DHCP server for our internal network is on a virtual server and our public is located on the DMZ interface on our Firewall, and yes, this is only happening when trying to get on our internal network.
You could be onto something with the firmware Arison. Prior to installing AP130s we only had AP120 and 121 devices, running v5 firmware with a v5 Hivemanager. When we purchased a number of new AP130s, I upgraded everything to the latest v6 versions and that's approximately when DHCP problems started happening for us too
As I mentioned above, enabling DHCP relays on all APs seemed to resolve most of the DHCP problems on the guest/non-corporate VLAN (even though relays shouldn't technically be required) and of course it does generate some unnecessary DHCP chatter. We still get the occasional DHCP problem on that VLAN but not as much as before
The corporate VLAN also still suffers from DHCP problems on wifi - while the wired clients on the corporate VLAN have no issues. I won't enable relays on that VLAN, as the additional chatter wouldn't be desirable. Unfortunately I haven't had enough time to troubleshoot it further, and I haven't engaged Aerohive yet, mainly because it's so intermittent
I just saw that HiveOS 6.6r2 Irvine.2309 is available now. I am going to test that now and see if the problem comes back.
Have any of you by any chance checked the box on the SSID config that says “Disable multicast and broadcast traffic forwarding onto wireless”? I didn’t have time to test it rigorously, but I seem to remember having an unexpected behavior with DHCP when that was checked, I could be wrong though. I have put some IP firewall policies in place to specifically allow DHCP Server and DHCP client traffic so I don’t have to worry about it.
Something like this...
ip-policy VLAN1_From id 3 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service DHCP-Server action permit
ip-policy VLAN1_To id 3 from 0.0.0.0 0.0.0.0 to 0.0.0.0 0.0.0.0 service DHCP-Client action permit
I upgraded another site to HiveOS 6.5r3 Honolulu.2530 to see what happened, almost instantly there were complaints of DHCP problems - I highly suspect something is dodgy in this firmware but nobody who is meant to be providing support knows about it.
It's not the first time I've had DHCP problems with Aerohive APs, the bug just goes away for a bit when certain releases come out.
Finally got around to upgrading to HM 6.6r3 and HiveOS 6.6r2a (from 6.5r1). Initial indications are good for DHCP although time will tell. I tried to use HiveOS6.6r1b as most people were reporting success with that, but HM wouldn't upload it for some reason. JonnyM had also seen a DHCP fix mentioned in the release notes of HiveOS 6.6r2a so I'm giving that one a try, and my test machine (Surface Pro 2) that was failing consistently when switching between SSIDs has now started working
Still going great after 3 months - not a single DHCP issue
AP130 APs all running 6.6r2a
AP120 and AP121 APs all running 6.5r3a
Hivemanager on 6.6r3a