Devices behind wireless bridge do not getting an ip addresses from DHCP

  • 1
  • Question
  • Updated 5 days ago
  • Answered
  • (Edited)
I have 7372 AP running 100.1.x.x.x... (jsut updated today). Everything works fine except for a device that is connected to a wireless bridge. The device will not get an ip address from the DHCP. I have Ruckus configured with static ip, the wireless bridge (Netgear 3001) is configured to obtain an ip address from the DHCP server and it is working perfectly fine only the device that is behind the Wireless bridge is not getting the ip from the DHCP. The Device connected to the Wireless Bridge will work if assigned a static ip address.

SO to conclude is there anything that needs to be done to make the DHCP available for host behind a wireless bridge ? I switched from Ubiquity AP where this Wireless Bridge was working perfectly fine (there are not many setting on it anyway).

Any help will be appreciated.

Thank you
Photo of Chris Lasek

Chris Lasek

  • 4 Posts
  • 0 Reply Likes

Posted 3 years ago

  • 1
Photo of Munish Dhiman

Munish Dhiman

  • 100 Posts
  • 15 Reply Likes
Hi Chris,

Where is the DHCP server located , could you draw the topology ?

Thanks 
Munish 
Photo of Chris Lasek

Chris Lasek

  • 4 Posts
  • 0 Reply Likes

It is really nothing special no DHCP helpers involved etc. It is a flat network, 10.0.100.X/24. The gateway and the DHCP server are on 10.0.100.1, the Ruckus AP is on 10.0.100.8. I can confirm that the DHCP server is operational as all other devices are getting ips from it.   


Thank you

Photo of Robert Punsal

Robert Punsal, Employee

  • 4 Posts
  • 2 Reply Likes
Ruckus does not officially support third party wireless bridge. According to PLM, "There is no standard connection format that allows the wifi connection to “host” multiple MAC addresses.  i.e.: multiple Ethernet devices on the bridge Ethernet ports but showing up as unique clients on the wireless system".
Photo of Chris Lasek

Chris Lasek

  • 4 Posts
  • 0 Reply Likes

So how do you guys do this with VMWARE, if I have a VMWARE Workstation on a PC connected via Wireless and given the Bridged network connection ?

Would I have to use the NATEed host ip address (which is an option on the VM) ?

Photo of Michael Brado

Michael Brado, Official Rep

  • 2430 Posts
  • 335 Reply Likes
We might have an option to work thru the bridge, if you can test it.

When attempting to connect non-Ruckus wireless bridge devices, we can test by disabling
directed-DHCP, our proprietary conversion of broadcast to unicast of DHCP offer and ack
messages, and evaluate how this affects the WDS with wireless bridge clients.

rkscli: set qos directedDHCP
usage: set qos directedDHCP {enable|disable}
rkscli:

From ZD CLI: remote_ap_cli –A “set qos directedDHCP disable”

The “-A” switch before the double-quoted AP command, means apply to all currently connected APs.

Photo of Chris Lasek

Chris Lasek

  • 4 Posts
  • 0 Reply Likes

This worked perfectly - now any device behind the bridge is able to get an ip.


Thank you

Photo of Michael Brado

Michael Brado, Official Rep

  • 2430 Posts
  • 335 Reply Likes

Clarification, the ZD CLI command is run from ZD Debug mode.

ruckus# remote_ap_cli
Invalid command "remote_ap_cli". The command is either unrecognized or incomplete. To view a list of commands that you can run  from this context, type '?' or 'help'.
ruckus# debug
You have all rights in this mode.
ruckus(debug)# remote_ap_cli

usage: remote_ap_cli [-q] {-a ap_mac | -A } "cmd arg1 arg2 .."
       excute AP CLI command in remote AP
       -A ; all connected AP's
       -q ; do not show result
       cmd ; Ruckus CLI, e.g. "get station wlan0 list"
ruckus(debug)#

Photo of Charles Sprickman

Charles Sprickman

  • 8 Posts
  • 7 Reply Likes
I hate to resurrect such an old thread, but google led me here, as I was having the same problem and this workaround "fixed" it.  Are there any plans to offically support this functionality without disabling the "directed DHCP" feature (which sounds like something I'd rather not disable permanently on a busy network)?

It's also tough to troubleshoot - I kept thinking something was amiss with how I copied my VMs to this new laptop, came >this< close to reinstalling the VM. :)

Just FYI, the problem seems to be getting the traffic from the DHCP server back to the client.  The server is seeing the requests and offering an IP, the client just never sees the traffic.  Here's a log, this is a flat L2 network, the DHCP server is ISC-DHCPD on pfsense, and the MAC you see in the logs is the MAC of the virtual machine (apologies for reverse chronological order):

Sep 8 21:34:19	dhcpd	DHCPOFFER on 10.3.2.207 to 00:50:56:38:7c:40 (fruitcake-fusion) via bge0	
Sep 8 21:34:19	dhcpd	DHCPDISCOVER from 00:50:56:38:7c:40 (fruitcake-fusion) via bge0	
Sep 8 21:34:10	dhcpd	DHCPOFFER on 10.3.2.207 to 00:50:56:38:7c:40 (fruitcake-fusion) via bge0	
Sep 8 21:34:10	dhcpd	DHCPDISCOVER from 00:50:56:38:7c:40 (fruitcake-fusion) via bge0	Sep 8 21:34:06	dhcpd	DHCPOFFER on 10.3.2.207 to 00:50:56:38:7c:40 (fruitcake-fusion) via bge0	
Sep 8 21:34:06	dhcpd	DHCPDISCOVER from 00:50:56:38:7c:40 (fruitcake-fusion) via bge0	Sep 8 21:33:34	dhcpd	DHCPOFFER on 10.3.2.207 to 00:50:56:38:7c:40 (fruitcake-fusion) via bge0	
Sep 8 21:33:34	dhcpd	DHCPDISCOVER from 00:50:56:38:7c:40 (fruitcake-fusion) via bge0	Sep 8 21:33:17	dhcpd	DHCPOFFER on 10.3.2.207 to 00:50:56:38:7c:40 (fruitcake-fusion) via bge0	Sep 8 21:33:17	dhcpd	DHCPDISCOVER from 00:50:56:38:7c:40 (fruitcake-fusion) via bge0
Photo of Stephen Hall

Stephen Hall

  • 10 Posts
  • 0 Reply Likes
I have 2 questions in reguards to directed dhcp disabling.

1- Am i correct in that the "solution" above:
From ZD CLI: remote_ap_cli –A “set qos directedDHCP disable”

will NOT survive AP or ZD reboots?   (ie post AP and/or ZD reboot, directed dhcp will again be enabled).


2-  where can we get specifics on the pros/cons of directed dhcp? 
(a search of the KB for directedDHCP   or directed DHCP  - yielded many un-related results)

thanks
Photo of Michael Brado

Michael Brado, Official Rep

  • 2430 Posts
  • 335 Reply Likes
1. ZD reboots will not affect this command if it has been issued to the APs.What you are saying is configure all APs "-A" with the 'set qos directedDHCP disable' command.  I believe an AP reboot will reset this to default.
2. The primary purpose of this command is for clients behind wireless bridges, whose MACs are not "seen" by our AP that the bridges connect to.  This will allow a client Unicast IP response to pass across the bridges (hopefully).
(Edited)
Photo of Stephen Hall

Stephen Hall

  • 10 Posts
  • 0 Reply Likes
Thanks for reply.
>I believe an AP reboot will reset this to default.  
wow, is there anyway to make this survive AP reboots of a controller based AP?  (besides moving to all standalone ruk APs only).   
Clearly there are scenarios where wifi bridged repeaters will need to be deployed (ie a unit with no cat5 , ie repeat same ssid even with a dual radio/5g back-haul repeater, 2.4g only to clients)
unless im reading this wrong the lack of ability to permanently make this change blocks the possibility of any repeaters ever (as a site power event or AP reboot will stop all working repeaters from working)

> 2. The primary purpose of this command is for clients behind wireless bridges,

I understand the need for this disable command,  my question was in regards to why ruckus added / uses directedDHCP qos by default?   
is it purposely to block providers use of repeaters ? 
or is it (as i assume) to help reduce broadcast traffic across the ethernet side ? 
(if so is this reduction only on the Ethernet side of a flat L2 network or does it also help/reduce wireless spectrum utilization in anyway)?