DHCP Across Wireless Bridge
Anthony Hoppe
anthony.hoppe at gmail.com
Tue Dec 31 05:35:57 UTC 2013
Hi Glenn,
This seems to have done the trick! Thanks! I think this is definitely
a case of "RTFM." I am going to become a lot more familiar with the
dhcpd.conf man page.
While I'm becoming familiar with the dhcpd.conf man page, perhaps you or
another member of this list can help with a related question:
Right now, I have "always-broadcast on;" set for an entire subnet.
Ideally, I'd like to only have this set whenever DHCP requests come from
devices that appear to be behind the wireless bridge (will have the
originating MAC of 00:02:6f:9b:fe:52). Would it be possible to write a
class to achieve this? Something like the following (I am taking a
complete stab in the dark here)?
class "WirelessBridge" {
match hardware;
}
subclass "WirelessBridge" 1:00:02:6f:9b:fe:52;
Even if the above is remotely correct, I'm not sure how to write
"always-broadcast for clients in class WirelessBridge".
Thanks!
~ Anthony
On 12/30/2013 06:57 PM, Glenn Satchell wrote:
> Hi Anthony
>
> Looks like you want the always-broadcast flag set to true. This is form
> the dhcpd.conf man page.
>
> The always-broadcast statement
>
> always-broadcast flag;
>
> The DHCP and BOOTP protocols both require DHCP and BOOTP
> clients to set the broadcast bit in the flags field of the
> BOOTP message header. Unfortunately, some DHCP and BOOTP
> clients do not do this, and therefore may not receive
> responses from the DHCP server. The DHCP server can be
> made to always broadcast its responses to clients by set-
> ting this flag to 'on' for the relevant scope; relevant
> scopes would be inside a conditional statement, as a
> parameter for a class, or as a parameter for a host
> declaration. To avoid creating excess broadcast traffic
> on your network, we recommend that you restrict the use of
> this option to as few clients as possible. For example,
> the Microsoft DHCP client is known not to have this prob-
> lem, as are the OpenTransport and ISC DHCP clients.
>
> regards,
> -glenn
>
> On Tue, December 31, 2013 9:37 am, Anthony Hoppe wrote:
>> I've done a dhcpdump of my Lubuntu laptop obtaining a DHCP address from
>> my Cisco 871 router. See the link below:
>>
>> http://pastebin.com/FE0iuVEB
>>
>> It looks like Cisco's implementation of DHCP has all communication as
>> broadcast (with "chaddr" containing the respective client's MAC), as
>> opposed to isc-dhcp-server responding directly to the client. This
>> would explain why Cisco's DHCP functions across the wireless bridge.
>>
>> Is there a way to configure isc-dhcp-server to function similarly?
>>
>> In most cases I can understand why you wouldn't want to do this, but I
>> can see it as helpful in other situations (like mine :-D).
>>
>> ~ Anthony
>>
>> On 12/29/2013 10:33 AM, Anthony Hoppe wrote:
>>> Hi Glenn,
>>>
>>> Thank you for the response! I've done done a few tests using dhcpdump.
>>> Below are the results.
>>>
>>> http://pastebin.com/Ns8jmzSu - This is a server-side dhcpdump showing my
>>> Dish VIP722 DVR, connected via the wireless bridge, attempting to obtain
>>> an address.
>>>
>>> http://pastebin.com/9yMEUtLG - (Pair 1) Another server-side run of
>>> dhcpdump showing a Lubuntu laptop, connected via the wireless bridge,
>>> attempting to obtain an address.
>>>
>>> http://pastebin.com/CrzfVJRd - (Pair 1) This is a client-side run of
>>> dhcpdump showing the Lubuntu laptop, connected to the wireless bridge,
>>> attempting to obtain an address. It never receives a DHCPOFFER
>>> response.
>>>
>>> http://pastebin.com/LrRD1wac - (Pair 2) This is a server-side run of
>>> dhcpdump showing the Lubuntu laptop, hardwired to the network normally
>>> (NOT using the wireless bridge), successfully obtaining an address.
>>>
>>> http://pastebin.com/EjVszsMS - (Pair 2) And lastly, this is a
>>> client-side run of dhcpdump showing the Lubuntu laptop, hardwired to the
>>> network normally (NOT using the wireless bridge), successfully obtaining
>>> an address.
>>>
>>> It looks like the wireless bridge is preventing the DHCPOFFER response
>>> from reaching the client. The DHCPDISCOVER broadcast is received by the
>>> DHCP server with the MAC address of the wireless bridge as the source.
>>> The DHCPDISCOVER broadcast has a request to redirect the response to
>>> the MAC address of the client, which it looks like the DHCP server is
>>> obeying this request. But, for some reason, the DHCPOFFER response
>>> never makes it to the client.
>>>
>>> Is there a way I can configure isc-dhcp-server and/or the OS it's
>>> running on to work around this? The Cisco DHCP server seems to do
>>> things differently that makes this a non-issue. Could it be that the
>>> DHCPOFFER needs to have a destination of the wireless bridge with a
>>> redirect request to the MAC address of the client? I don't know...
>>>
>>> Thanks for the pointers on my configuration. I fixed the dynamic address
>>> range so that it does not include the broadcast address (oops!), and I
>>> modified the fixed address for host dwight so that it's outside the
>>> dynamic address range. It didn't help this particular problem, but it's
>>> always good to follow best practice.
>>>
>>> ~ Anthony
>>>
>>>
>>>
>>> On Sun, Dec 29, 2013 at 2:40 AM, Glenn Satchell
>>> <glenn.satchell at uniq.com.au <mailto:glenn.satchell at uniq.com.au>> wrote:
>>>
>>> Hi Anthony
>>>
>>> That config looks like it should be ok. As you are seeing the
>>> discover
>>> packets, then traffic is getting through from the clients and the
>>> dhcp
>>> server is replying. However the next thing should be a dhcp request
>>> packet
>>> from the client which you're not seeing.
>>>
>>> Can you run a packet capture on a client connected to the wireless
>>> bridge
>>> and see which parts of the traffic you can see? What you'd be
>>> looking for
>>> is whether the client sees the offer from the dhcp server, and if it
>>> does
>>> whether it then sends a dhcp request back to the server.
>>>
>>> Perhaps also try a packet capture on the dhcp server to see if the
>>> request
>>> is coming in, but is somehow not accepted by the dhcp server daemon.
>>>
>>> Two minor things with the config: the top end of the range is the
>>> broadcast address (10.7.17.255), perhaps reduce that to 10.7.17.254.
>>> The
>>> host dwight has a fixed ip address that is inside the dynamic range.
>>> While
>>> it may never be a problem, it's better to either break the range
>>> around
>>> that address (have two ranges: 100-199 and 201-254) or change it to
>>> have
>>> an ip outside the dynamic range. Neither of these two problems would
>>> stop
>>> dhcp working though.
>>>
>>> regards,
>>> -glenn
>>>
>>> On Sun, December 29, 2013 6:36 pm, Anthony Hoppe wrote:
>>> > Hello All,
>>> >
>>> > I've been experimenting with isc-dhcp-server on my home network
>>> and have
>>> > run into a snag. I have three devices (Xbox 360, Samsung Blu-Ray
>>> Player,
>>> > and a Dish VIP 722 HD-DVR) connected to a switch which connects
>>> to a
>>> > wireless bridge. In my previous setup (using my Cisco 871 router
>>> running
>>> > C870-ADVIPSERVICESK9-M ver 12.4(24)T as a DHCP server) these
>>> devices were
>>> > able to receive DHCP addresses without any problems. However,
>>> with
>>> > isc-dhcp-server, they are unable to receive addresses. Reviewing
>>> > /var/log/syslog shows many DHCPDISCOVER/DHCPOFFER pairings as
>>> seen below
>>> > (an example of one device):
>>> >
>>> > -----
>>> >
>>> > Dec 28 23:28:13 dns dhcpd: DHCPDISCOVER from 00:08:89:e4:dd:df
>>> via eth0
>>> > Dec 28 23:28:13 dns dhcpd: DHCPOFFER on 10.7.17.101 to
>>> 00:08:89:e4:dd:df
>>> > via eth0
>>> > Dec 28 23:28:15 dns dhcpd: DHCPDISCOVER from 00:08:89:e4:dd:df
>>> via eth0
>>> > Dec 28 23:28:15 dns dhcpd: DHCPOFFER on 10.7.17.101 to
>>> 00:08:89:e4:dd:df
>>> > via eth0
>>> > Dec 28 23:28:17 dns dhcpd: DHCPDISCOVER from 00:08:89:e4:dd:df
>>> via eth0
>>> > Dec 28 23:28:17 dns dhcpd: DHCPOFFER on 10.7.17.101 to
>>> 00:08:89:e4:dd:df
>>> > via eth0
>>> > Dec 28 23:28:31 dns dhcpd: DHCPDISCOVER from 00:08:89:e4:dd:df
>>> via eth0
>>> > Dec 28 23:28:31 dns dhcpd: DHCPOFFER on 10.7.17.101 to
>>> 00:08:89:e4:dd:df
>>> > via eth0
>>> > Dec 28 23:28:33 dns dhcpd: DHCPDISCOVER from 00:08:89:e4:dd:df
>>> via eth0
>>> > Dec 28 23:28:33 dns dhcpd: DHCPOFFER on 10.7.17.101 to
>>> 00:08:89:e4:dd:df
>>> > via eth0
>>> > Dec 28 23:28:35 dns dhcpd: DHCPDISCOVER from 00:08:89:e4:dd:df
>>> via eth0
>>> > Dec 28 23:28:35 dns dhcpd: DHCPOFFER on 10.7.17.101 to
>>> 00:08:89:e4:dd:df
>>> > via eth0
>>> > Dec 28 23:28:49 dns dhcpd: DHCPDISCOVER from 00:08:89:e4:dd:df
>>> via eth0
>>> > Dec 28 23:28:49 dns dhcpd: DHCPOFFER on 10.7.17.101 to
>>> 00:08:89:e4:dd:df
>>> > via eth0
>>> > Dec 28 23:28:51 dns dhcpd: DHCPDISCOVER from 00:08:89:e4:dd:df
>>> via eth0
>>> > Dec 28 23:28:51 dns dhcpd: DHCPOFFER on 10.7.17.101 to
>>> 00:08:89:e4:dd:df
>>> > via eth0
>>> > Dec 28 23:28:53 dns dhcpd: DHCPDISCOVER from 00:08:89:e4:dd:df
>>> via eth0
>>> > Dec 28 23:28:53 dns dhcpd: DHCPOFFER on 10.7.17.101 to
>>> 00:08:89:e4:dd:df
>>> > via eth0
>>> >
>>> > -----
>>> >
>>> > Connecting a known working computer to the switch behind the
>>> wireless
>>> > bridge also results the same...it is not able to obtain a DHCP
>>> address.
>>> > DHCP works anywhere else on the network without a hitch.
>>> >
>>> > Some Googling around leads me to believe the culprit is likely
>>> the
>>> > wireless
>>> > bridge. I am using an EnGenius WAP (I can't find and/or recall
>>> the model
>>> > at the moment) in client bridge mode. However, like I said
>>> earlier, DHCP
>>> > worked fine in my previous setup. Is there a way to configure
>>> > isc-dhcp-server so that it will work, too?
>>> >
>>> > Here is my dhcpd.conf:
>>> >
>>> > -----
>>> >
>>> > authoritative;
>>> > option domain-name "hhsn.net <http://hhsn.net>";
>>> > option domain-name-servers 10.7.17.24;
>>> >
>>> > ddns-updates on;
>>> > ddns-update-style interim;
>>> > ignore client-updates;
>>> > update-static-leases on;
>>> >
>>> > default-lease-time 86400;
>>> > max-lease-time 86400;
>>> > log-facility local7;
>>> >
>>> >
>>> > include "/etc/dhcp/ddns.key";
>>> >
>>> > zone hhsn.net <http://hhsn.net>. {
>>> > primary 10.7.17.24;
>>> > key DDNS_UPDATE;
>>> > }
>>> >
>>> > zone 17.7.10.in-addr.arpa. {
>>> > primary 10.7.17.24;
>>> > key DDNS_UPDATE;
>>> > }
>>> >
>>> >
>>> > subnet 10.7.17.0 netmask 255.255.255.0 {
>>> > range 10.7.17.100 10.7.17.255;
>>> > option routers 10.7.17.1;
>>> > option broadcast-address 10.7.17.255;
>>> > option subnet-mask 255.255.255.0;
>>> > }
>>> >
>>> > host dwight {
>>> > hardware ethernet 00:23:DF:7F:28:04;
>>> > fixed-address 10.7.17.200;
>>> > }
>>> >
>>> > host nettalk {
>>> > hardware ethernet 00:25:F6:00:3A:B4;
>>> > fixed-address 10.7.17.20;
>>> > }
>>> >
>>> > -----
>>> >
>>> > Any assistance would be greatly appreciated. I am using
>>> isc-dhcp-server
>>> > version 4.2.2 on Debian 7.
>>> >
>>> > Thanks!
>>> >
>>> > ~ Anthony
>>>
>>>
>>> _______________________________________________
>>> dhcp-users mailing list
>>> dhcp-users at lists.isc.org <mailto:dhcp-users at lists.isc.org>
>>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>>
>>>
>> _______________________________________________
>> dhcp-users mailing list
>> dhcp-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/dhcp-users
>>
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
More information about the dhcp-users
mailing list