topic Re: Devices behind wireless bridge do not getting an ip addresses from DHCP in To Be Moved

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

chris_lasek — Tue, 31 Mar 2015 18:07:01 GMT

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

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

munish_munish — Tue, 31 Mar 2015 18:48:48 GMT

Hi Chris,

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

Thanks
Munish

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

chris_lasek — Tue, 31 Mar 2015 18:54:46 GMT

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

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

robert_punsal — Tue, 31 Mar 2015 20:29:50 GMT

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".

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

michael_brado — Tue, 31 Mar 2015 20:36:32 GMT

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.

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

michael_brado — Tue, 31 Mar 2015 20:41:10 GMT

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)#

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

chris_lasek — Tue, 31 Mar 2015 20:44:56 GMT

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) ?

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

chris_lasek — Tue, 31 Mar 2015 21:04:55 GMT

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

Thank you

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

charles_sprick1 — Sat, 09 Sep 2017 01:47:00 GMT

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

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

stephen_hall_60 — Sun, 03 Jun 2018 00:49:35 GMT

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

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

michael_brado — Mon, 04 Jun 2018 16:27:48 GMT

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).

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

stephen_hall_60 — Tue, 17 Jul 2018 05:07:04 GMT

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)?