DHCP delivery not stable

  • 1
  • Question
  • Updated 1 year ago
I am having issued with DHCP delivery to clients on an 802.1x SSID on my AeroHive based network.
We run AeroHive WiFi with HP Procurve switching. At this point it is a flat class B network for everything - no firewalls or ACLs. The DHCP is delivered from a Windows 2012R2 server and no issues are seen on the wired network.
All my APs - mix of 330, 130, and 230 units - are displaying this issue. AeroHive have recommended that I load the 6.5r6 golden release on them which has been done but at this stage does not seem to make any difference to the issue. I am running 6.8r7a HMOL.

We are currently moving from PPSK to 802.1x - backended by CloudPath. The interesting issue that I have is that a user will be connecting to the 802.1x SSID and not getting an IP address, change them to use one of the old PPSK SSID - IP address is delivered no problems.
The only thing that I have found in the logs that looks odd is that I get the following:
2017-03-01T11:45:53.209727+11:00 ah-783280.local kernel: [fe]: DHCP bcast set? no, client mac 7c04:d0b9:9908, out_ifp n/a
2017-03-01T11:45:53.209973+11:00 ah-783280.local kernel: [fe]: convert DHCP reply to unicast 7c04:d0b9:9908

Interesting because I have checked and I do not have the flag to block broadcast going to the WiFi set. From my investigation it would appear that this unicast packet is not received by the client, or not received before the timeout. Due to the intermittent nature of the issue I have not been able to set up Wireshark and catch the issue on a client.

It is not possible to replicate the issue as it does not happen every time. Some users get on first go some do not. Those that do get on might work for an hour, or a day, or a couple of days then they get the issue - I believe that this happens on a refresh of the DHCP by the client. If they wait, turn the wifi on and off a random number of times, they get back on.
Clients displaying the issue are predominately Macs with a mix of OS from 10.10.5 to 10.12.1. The issue has been seen on some Windows 8.1 and 10 devices as well. This count is probably skewed as we are a school and most of our users have Macs. No uses have complained of the issues on iPads, iPhones, or Android devices to date.

Find brick wall, beat head - about as effective as everything else I have tried to date!
Any suggestions gratefully received.
Photo of Ross Gailer

Ross Gailer

  • 4 Posts
  • 0 Reply Likes
  • very frustrated

Posted 1 year ago

  • 1
Photo of Hans Matthé

Hans Matthé

  • 42 Posts
  • 2 Reply Likes
Hello Ross

Maybe this can be an article to take a look at (because you mention the Apple devices). It is about the way Apple configures power saving and the DTIM packets (packets are used to wake up devices before broadcast traffic occurs):
http://www.sniffwifi.com/2016/05/go-to-sleep-go-to-sleep-go-to-sleep.html

It's a wild gues offcourse.

grtz
Photo of Ross Gailer

Ross Gailer

  • 4 Posts
  • 0 Reply Likes
Hans,
Thanks for the reply.
Had a read through the article. While it deals with iOS devices rather than Macbooks, it is still worth a look.
Checked the DTIM interval on the 802.1x SSID and it was set to 1 - which I believe is the default. Set it to 4 following the suggestion of a minimum of 3 from the article. Will see if it makes a difference.
Photo of Metka Dragos

Metka Dragos

  • 51 Posts
  • 11 Reply Likes
Ross,
please open a support ticket.
Photo of Ross Gailer

Ross Gailer

  • 4 Posts
  • 0 Reply Likes
I have had Australian Support looking at this through our reseller - the reseller has the ticket in their name. I do not have, according to AeroHive, direct access to support because I am in Australia and I work through a reseller.
Photo of Ross Gailer

Ross Gailer

  • 4 Posts
  • 0 Reply Likes
Thanks to Hans above, it would appear that my issue has been resolved. I have set the DTIM to 4 from the default of 1 and have turned off DAS. The DHCP delivery to the clients has now been stable for 3 days on the 802.1x SSID. An additional benefit has been the increased call reliability on our Mitel 5624 WiFi handsets.
Our reseller is talking to AeroHive support to see if they can make any sense of this as they do not believe that this should have made a difference.