Has anyone seen devices showing up in HiveManager with 0.0.0.0 ip addresses?

  • 2
  • Question
  • Updated 2 years ago
  • Answered
I have a client with an on-premise HiveManager and they are seeing devices show up in the Client list that have 0.0.0.0 ip addresses.
The DHCP is served from Cisco Catalyst 3750 switches, and the DHCP pool is definitely large enough.
This issue apparently was evident on HiveOS 5.1 and 6.0, and is not device or AP specific. Usually a restart of the AP fixes it.

Anyone have any ideas?
Photo of Aaron Scott

Aaron Scott

  • 43 Posts
  • 9 Reply Likes

Posted 5 years ago

  • 2
Photo of Brian Powers

Brian Powers, Champ

  • 396 Posts
  • 92 Reply Likes
Its been some time, but the few times that I've seen the 0.0.0.0 IP on a client device was an iOS device that had been asleep for extended periods of time.

For instance, the device (iPad for instance) was asleep and left the BSSID area. And unused while it was gone. It would come back (say for work the next day) and while still in its "sleep" state, it would initiate somewhat the DHCP request since its was back in the BSSID area but it would stop and stay at a 0.0.0.0 IP until the device was woken up.

Other than that, thats the only time I recollect seeing a client in this state.
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
The only time you should see a client with a 0.0.0.0 IP address is when that client has not completed layer two authentication (or the HiveManager has not been updated that the client has yet).

If a Windows client associates does the reported IP address change from 0.0.0.0 to a 169.254.x.x IP address?

The strange thing here is that it appears that the DHCP service initially works, fails at some point and then, after an access point reboot, appears to work again. If the issue was a firewall rule or an incorrect/non-existent IP Helper statement then a reboot of an access point would not resolve the issue.

Once you have an access point that associating clients fail to get an IP address on enable remote sniffing and see if:

1. The wireless client is sending a DHCP request
2. A DHCP response is being sent back to the wireless client
Photo of Aaron Scott

Aaron Scott

  • 43 Posts
  • 9 Reply Likes
The client monitor showed the DHCP Discovery, and DHCP Offer, but no DHCP Request ever comes back from the client device, so the DHCP server resends the DHCP Offer (repeatedly).

Is it possible that the Band Steering is shifting the client prior to DHCP finishing and that is causing the 0.0.0.0 IPs?
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
I can't imagine that band steering is causing your issue as any band steering occurs before the client associates to a radio.

I would try the following:

* Install WireShark v1.10.0 onto a Windows client, if it is not already installed, and you can select the "Wireless Network Connection" as your interface.

* Ensure that the Windows client is not associated to the wireless network and start a capture.

* Associate the Windows client to the wireless network and look for the DHCP traffic.

What you need to determine is:

1. Is the DHCP offer making it to wireless client? If not, as the client monitor is showing the DHCP offer, the access point must be dropping the DHCP offer.

2. If the DHCP offer is making it to the wireless client is the the wireless client responding?
Photo of Aaron Scott

Aaron Scott

  • 43 Posts
  • 9 Reply Likes
Thanks for the ideas.

Unfortunately the devices that misbehave are random, so getting a machine that has WireShark on it to play up might be difficult.

Would it be of a benefit to move the DHCP server from the switch to a Windows Server (for more visibility)?
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
You could set up a temporary DHCP scope on the access points as that would remove any LAN equipment from the issue.

Otherwise moving the DHCP service from the switch to a Windows Server sounds like a good option. If the issue disappears then you know the issue is caused by something on the switch.
Photo of Aaron Scott

Aaron Scott

  • 43 Posts
  • 9 Reply Likes
i have the client looking for a misbehaving laptop to grab a packet capture from.

Also suggested the relocation of the DHCP server.

I'll let you know what happens.

Thanks for the help!
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Was there ever a definitive answer on the causal factors behind seeing an IP of 0.0.0.0?
(Edited)
Photo of gerjimi

gerjimi

  • 17 Posts
  • 1 Reply Like
Having the same issue. Only IOS or MacOS devices. DHCP server is a Windows 2003. Computers or devices get the IP, then they go sleep mode, no more IP after they wake up. I see this on the AP log:

2015-11-25 12:17:51 info    ah_auth: Send station (8438:3560:7e30) session sync query count (0) to old ap (d854:a222:0154) (192.168.98.250) time sec(1448482671) usec(200705)2015-11-25 12:17:51 info    amrp2: set proxy route: 8438:3560:7e30 -> d854:a221:2a00 ifp wifi0.1 upid 0 flag 0x1c03 monitor(0/0) pkt/sec ok
2015-11-25 12:17:51 info    kernel: [mesh]: set proxy : 8438:3560:7e30 d854:a221:2a00 wifi0.1 flag 0x1c03
2015-11-25 12:17:51 info    amrp2: receive event <STA join>: 8438:3560:7e30 (ip 0.0.0.0) associate wifi0.1 upid 0 vlan 1 flag 0x00000000
2015-11-25 12:17:51 info    capwap: receive event it-tool-kit notify event to capwap-client: eventid = 71: length = 147
2015-11-25 12:17:51 info    ah_auth: add new RT sta: MAC=8438:3560:7e30, IP=0.0.0.0, hostname=, username= on wifi0.1
2015-11-25 12:17:51 info    ah_auth: [Auth]STA(8438:3560:7e30) login to SSID(wifi0.1) by user_name=
2015-11-25 12:17:51 info    capwap: receive event it-tool-kit notify event to capwap-client: eventid = 71: length = 118
2015-11-25 12:17:51 info    capwap: receive event it-tool-kit notify event to capwap-client: eventid = 71: length = 143
2015-11-25 12:17:51 warn    ah_auth: received EAPOL-Key frame (4/4 Pairwise)
2015-11-25 12:17:51 info    capwap: receive event it-tool-kit notify event to capwap-client: eventid = 71: length = 142
2015-11-25 12:17:51 info    capwap: receive event it-tool-kit notify event to capwap-client: eventid = 71: length = 143
2015-11-25 12:17:51 warn    ah_auth: sending 3/4 msg of 4-Way Handshake
2015-11-25 12:17:51 warn    ah_auth: received EAPOL-Key frame (2/4 Pairwise)
2015-11-25 12:17:51 info    capwap: receive event it-tool-kit notify event to capwap-client: eventid = 71: length = 142
2015-11-25 12:17:51 info    capwap: receive event it-tool-kit notify event to capwap-client: eventid = 71: length = 132
2015-11-25 12:17:51 warn    ah_auth: broadcom_new_sta: set acct mac
2015-11-25 12:17:51 warn    ah_auth: sending 1/4 msg of 4-Way Handshake
2015-11-25 12:17:51 warn    ah_auth: start authentication
2015-11-25 12:17:51 warn    ah_auth: event 1 notification
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
An address of 0.0.0.0 actually just means that an IP address hasn't been snooped by HiveOS, it's a null state if you will.
Photo of Anders Andersson

Anders Andersson

  • 2 Posts
  • 0 Reply Likes
Same problem here! Large city network, over 2000 users trying to connect to 390 APs residing on different WAN links. Most of them succeed but a random number cannot connect. We see the DHCP Request leaving the client but it never shows in the AP. In the AP we only see DHCP Discover and a number of DHCP Offers.

Everything worked like a charm when we had an ISA Server on the central site acting as DHCP Server and Internet gateway. Our client then decided to change ISP and their DHCP service resides on a network far away behind a router. DHCP relay is configured and working since most of the clients can connect.

The new ISP says that nothing is wrong in their end and "they have other customers running the same solution without problems".

Anyone?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Same as my answer above. If you have DHCP problems, you need to diagnose that by performing appropriate packet captures and analysis through the points in the chain.

Perhaps go for a divide and conquer approach to lock in on the root cause of the problem.

Also take a look at the output of Aerohive's Client Monitor.

An address of 0.0.0.0 is a symptom not a cause, so it won't help you triage much.

Cheers,

Nick
(Edited)
Photo of Luke Harris

Luke Harris

  • 265 Posts
  • 18 Reply Likes
Out of interest, what authentication method/s are you using?
Photo of Anders Andersson

Anders Andersson

  • 2 Posts
  • 0 Reply Likes
It ́s an open network without encryption. Authentication is made after successful connection by web login through the ISP