DHCP Across Wireless Bridge

Anthony Hoppe anthony.hoppe at gmail.com
Wed Jan 1 17:32:28 UTC 2014


Hi Glenn,

I know, and you're right.  It's not a big deal for my small home 
network.  I'm just a geek at heart and love to tinker. :-D

Until I stumble across something that'll enable me to do this, whether 
it's hacking the wireless bridge for option 82 support, or something 
else, I'll leave always-broadcast on for the entire subnet.

Or, who knows...maybe someday I'll finally get off my butt and run an 
ethernet cable to the side of my house utilizing the bridge.  Or, 
perhaps powerline ethernet adapters have improved since I last looked at 
them.  There are options for sure...

I might take what I learn tinkering with isc-dhcp-server and apply it at 
work (I'm a sysadmin for a medium sized K-8 school district).

~ Anthony

On 01/01/2014 01:32 AM, Glenn Satchell wrote:
> 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
>>
>
>
> _______________________________________________
> 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