DHCP Across Wireless Bridge
Glenn Satchell
glenn.satchell at uniq.com.au
Wed Jan 1 09:32:19 UTC 2014
In an enterprise with a huge address space it might be worth trying to get
this right. For a smallish home network I'd do one of two things:
* add a subclass for all the things behind the wireless bridge; or
* just turn on always-broadcast for everything.
It's probably not going to make that much difference.
regards,
-glenn
On Wed, January 1, 2014 5:54 am, Anthony Hoppe wrote:
> Hi Glenn,
>
> I'm shocked I was that close with constructing a class!
>
> The second MAC address you added as a second subclass is the Dish DVR I
> have set up behind the wireless bridge (one of three devices).
>
> Only having the subclass of the MAC address of the wireless bridge (or,
> at least, the MAC address that appears in server-side dhcpdumps) doesn't
> seem to work. Does this mean I'd need to have a subclass for every
> device behind the wireless bridge? Is there another way to construct
> the class/subclass to trigger based on the MAC address the DHCP traffic
> is coming from? I assume this is complicated since the DHCP traffic
> appears to come from MAC 00:02:6f:9b:fe:52 with a "CHADDR" value of the
> client itself.
>
> Is there a man page or document that details the various match options?
>
> ~ Anthony
>
> On 12/31/2013 12:17 AM, Glenn Satchell wrote:
>> Hi Anthony
>>
>> Just add that statement to the class definition, no need to mention the
>> class or the statement anywhere else, eg:
>>
>> class "WirelessBridge" {
>> match hardware;
>> always-broadcast on;
>> }
>> subclass "WirelessBridge" 1:00:02:6f:9b:fe:52;
>> # might also need this mac in the class, mentioned in the logs
>> subclass "WirelessBridge" 1:00:08:89:e4:dd:df;
>>
>> The other man pages to peruse are: dhcp-options, dhcp-eval, dhcpd. There
>> are a couple of others, but these are the main ones.
>>
>> regards,
>> -glenn
>>
>> On Tue, December 31, 2013 4:35 pm, Anthony Hoppe wrote:
>>> 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
>>>>
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> 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