Corrupt DHCP requests / packets

  • 2
  • Question
  • Updated 2 years ago
At a customers site we have the problem that it seems that there are corrupt DHCP fragments transmitted through the Access Points to our DHCP server.

E.g.:
MAC address of DHCP request: 1970f5789d80 (MAC AP is f09ce9789d80).
As you can see the first 6 characters of the MAC address (Vendor information) is diffrerent from the AP but not the last characters.

The requests is transmitted throug a seperate VLAN on our wireless network so the source can only be wireless devices.
Due to the DHCP information being corrupted our DHCP / DNS servers changes the DNS record(s) of the AP which automatically results in monitoring issues etc.

Our regular retailer does not have a clue, does anyone here have any ideas on this?
Or maybe some experience with the same?

Regards,
Maurice
Photo of Maurice van Zundert

Maurice van Zundert

  • 31 Posts
  • 1 Reply Like

Posted 2 years ago

  • 2
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Can you confirm that you are seeing this with HiveOS 6.5r3?

There was an issue in the internal beta of HiveOS 6.6r1 that did this which I discovered but it did not make it in in to the final release of 6.6r1 as it was corrected.

HiveOS 6.5r3 is newer than HiveOS 6.6r2. In most cases, you should be using this release of HiveOS.

Cheers,

Nick
(Edited)
Photo of John Fabry

John Fabry

  • 28 Posts
  • 8 Reply Likes
We have an issue with DHCP and versioning. If we run version 6.5r3 on a 230 DHCP fails. If we run 6.6r1 on the 330 DHCP fails. So, we are running version 6.5r3 on the 330s and version 6.6r1 on the 230s. Aerohive admits this is  a bug. This is working for us for the last 2 months. As of this morning there is no estimated fix date (release).
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
The fault in the 6.6r1 beta, for reference, was the OUI bits in Option 61 being randomised at boot:



This was caught and I thought corrected prior to release during normal pre-release testing processes, so I'm curious what slipped through the cracks.
(Edited)
Photo of Maurice van Zundert

Maurice van Zundert

  • 31 Posts
  • 1 Reply Like
Thanks for the replies, I got another push in the right direction by our default supplier.
They said that I could have something to do with roaming configurations, adjusting the default roaming options in the Hive settings could probably fix the issue.

I will take all in consideration!
Thanks!

Regards
Photo of Maurice van Zundert

Maurice van Zundert

  • 31 Posts
  • 1 Reply Like
AP230 + AP130 + AP1130
Same OS on our SR2124p and 2148p switches.
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Can you upgrade to 6.5r3 that is newer?
(Edited)
Photo of Maurice van Zundert

Maurice van Zundert

  • 31 Posts
  • 1 Reply Like
Have to load the image into the HM, I will check.
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
You need to ensure HM is updated to 6.6r3.
Photo of Maurice van Zundert

Maurice van Zundert

  • 31 Posts
  • 1 Reply Like
It is.
Photo of Ben Randall

Ben Randall

  • 3 Posts
  • 0 Reply Likes
I've found exactly this issue at one of my clients sites - "rogue" IP addresses assigned in various DHCP scopes assigned to the APs in which they don't have a management interface. 

The MAC address in the DHCP assignment always begins with 1970 and ends with digits matching the APs MAC.

This even occurs when the AP is not configured with a static IP address, so should not be making any DHCP client requests.

They are using AP1330's with v6.6r2a firmware and HMOL v6.6r3a - do we have any confirmation that this fault has been investigated?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Ben,

That issue is related to the Bonjour Gateway. It is expected that it will attempt to get an address in all the VLANs that the Bonjour Gateway is configured to operate in/scan. If you do not want this to happen, change the configuration.

That said, currently the OUI bits used are invalid in the Client MAC contained within DHCP Option 61, which we claim is a MAC address by setting the hardware type to Ethernet (1) when the value HiveOS uses is not a MAC address.

HiveOS uses what would be the OUI bits to encode VLAN information.



I am currently working on this via a support case that has been filed by a customer.

Regards,

Nick
(Edited)
Photo of Ben Randall

Ben Randall

  • 3 Posts
  • 0 Reply Likes
Hi Nick

Thanks for the pointer - I've just removed the default Bonjour Gateway from the configuration and it ~seems~ that the dodgy DHCP requests have stopped.

Fingers crossed that will fix the issue for me at least until a true fix is found.

Regards

Ben
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Hi Ben,

The customer found defect filled over this is CFD-1820.

Nick
(Edited)
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Just to update this thread...

The resolution to this CFD is likely to be setting the hardware type to 0 so that the Client-Identifier is not interpreted as being a MAC address by DHCP servers.

Nick
Photo of Devin

Devin

  • 17 Posts
  • 1 Reply Like
Thanks for the heads up!  I did remember to do it thankfully since I'm familiar with Cisco switches and routers.  The school we're helping out with this will be very happy if the commands work.
Photo of Devin

Devin

  • 17 Posts
  • 1 Reply Like
In a two hour period with about 400 unique connected clients during that time frame, there were 38 errors reading either "DHCP Server Unreachable" or "Incorrect Static IP or Gatewary" in the troubleshooting tab on HiveManager NG after those commands have been applied.  Any other ideas on what would be causing this?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Sorry to answer with a question, but, what troubleshooting steps have you carried out?

Usually DHCP issues are not issues with an AP but with the backing DHCP infrastructure behind it or the wired network.
Photo of Devin

Devin

  • 17 Posts
  • 1 Reply Like
I agree, the AP should be acting as a L2 bridge not touching DHCP at all which is why this is so perplexing.  Wired access works fine on any device which keeps me coming back to an AP problem.  Packet captures show numerous DHCP NAK packets with an Aerohive source MAC.  The APs all have static IPs so it seems like the AP is routing and the DHCP server is seeing the AP as the source MAC and not the client like it should so the DHCP server is saying, "hey man, quit asking me for IPs, you already have one!".  All firewalling and traffic filters are off, I did try turning on the dchp-relay agent but haven't seen a difference with that.  Here's an example packet capture I took:

Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Devin's issue is resolved.

For anybody else with issues, the correct workaround for the current  is just "alg sip enable" you do not need to disable QoS.
Photo of Maurice van Zundert

Maurice van Zundert

  • 31 Posts
  • 1 Reply Like
Hi Nick,

In our case it seems to have been the bonjour protocol.
This was responsible for the dodgy requests.

Regards, Maurice
Photo of Luke Harris

Luke Harris

  • 265 Posts
  • 18 Reply Likes
I'm still experiencing similar issues in my deployment. I have an Apple MacBook Air that won't get a DHCP address at a particular site. However when the device connects to the same SSID (network policy) at another site, they connect no problem. 

Having looked at client monitor I can see that the client is being put on the right VLAN so the NPS server is doing it's job. I then just see and endless string of 'Station sent out DHCP discover message' entries, which never generate a response.