DHCP+Failover over active PtP?

Lee1 2016-07-05 22:06:08 UTC #1

I've setup a pair of B5-Lites in a lab before installing for a customer in the field. I noticed that when the station reboots and connects to the AP, it still continues to use its failover IP, 192.168.1.20. Is the wired connection the only possible DHCP source? Is the B5-lite not running a BVI between the WLAN and LAN interfaces?

It's not a deal breaker, the APs should have a static IP anyways. I just thought it would eventually get an IP from DHCP once the link is up.

Chris 2016-07-05 23:34:13 UTC #2

Hi Lee,

The B5-Lite is able to obtain an IP address through the wireless link, so there must be some problem with a gateway, a network loop, or traffic encapsulation between routers on either end.

Please send a network diagram with connected equipment, and your support files so that we can see your configuration. Go to Diagnostics > Logs > Support Info > click the blue Support Files button to download a .tar file from each radio to your local computer, and then email the files to support@mimosa.co.

Lee1 2016-07-08 22:23:20 UTC #3

I think I've found a clue by looking at wireshark. It looks as if the AP requests a DHCP OFFER response to be unicast, but our Windows Server 2012 R2 is replying in a broadcast.

Lee1 2016-07-11 22:16:57 UTC #4

Not sure exactly what the issue is with Windows Server 2012 R2, but I was able to assign an IP across the wireless link when using a Cisco IOS DHCP server. I'm thinking it's the unicast vs. broadcast DHCP replies with Server 2012. The windows DHCP service will only reply via broadcast. I found a registry setting "IgnoreBroadcastFlag" and set it to 0 to make the service honor unicast requests. However, it just makes the service stop responding when unicast is requested and only respond when broadcast is requested.

Bryan1 2016-08-03 03:30:16 UTC #5

I have found this to be a problem when the DHCP source is a Sonicwall. It may be a similar issue. In this case, there is no local DHCP "server" as the link is a handful of clients only (for now) and the Sonicwall is handling the services I would normally have on a real server.

I wonder if anyone else has noted this using Sonicwall VPN/Firewall? Maybe there's an adjustment on the Sonicwall we can make.

I had to force a local IP address (static). It would have gotten one anyways, as you noted, static is a better plan, however during initial setup we were also testing DHCP assignments and the B5 station did not get one...Yet... clients connected and got assignments as expected.