DHCP Across Wireless Bridge
Robert C. Drye
Robert.C.Drye at hitchcock.org
Tue Dec 31 19:17:36 UTC 2013
Happy New Year!
130.189.219.218 130.189.219.218 255.255.255.255
130.189.240.111 130.189.240.111 255.255.255.255
130.189.240.116 130.189.240.116 255.255.255.255
130.189.240.194 130.189.240.194 255.255.255.255
130.189.241.236 130.189.241.236 255.255.255.255
130.189.241.57 130.189.241.57 255.255.255.255
130.189.241.58 130.189.241.58 255.255.255.255
130.189.242.167 130.189.242.167 255.255.255.255
130.189.240.115 130.189.240.115 255.255.255.255
130.189.242.173 130.189.242.173 255.255.255.255
130.189.162.14 130.189.162.14 255.255.255.255
130.189.243.151 130.189.243.151 255.255.255.255
130.189.160.216 130.189.160.216 255.255.255.255
130.189.160.217 130.189.160.217 255.255.255.255
130.189.160.218 130.189.160.218 255.255.255.255
130.189.160.232 130.189.160.232 255.255.255.255
130.189.161.7 130.189.161.7 255.255.255.255
130.189.161.8 130.189.161.8 255.255.255.255
130.189.161.167 130.189.161.167 255.255.255.255
130.189.161.168 130.189.161.168 255.255.255.255
130.189.160.110 130.189.160.110 255.255.255.255
130.189.241.12 130.189.241.12 255.255.255.255
130.189.241.133 130.189.241.133 255.255.255.255
130.189.161.11 130.189.161.11 255.255.255.255
130.189.172.0/255.255.255.0 130.189.172.0 255.255.255.0
130.189.219.119 130.189.219.119 255.255.255.255
-----Original Message-----
From: dhcp-users-bounces+robert.c.drye=hitchcock.org at lists.isc.org [mailto:dhcp-users-bounces+robert.c.drye=hitchcock.org at lists.isc.org] On Behalf Of Anthony Hoppe
Sent: Tuesday, December 31, 2013 1:54 PM
To: Users of ISC DHCP
Subject: Re: DHCP Across Wireless Bridge
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
IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE:
This message is intended for the use of the person to whom it is addressed and may contain information that is privileged, confidential, and protected from disclosure under applicable law. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records.
More information about the dhcp-users
mailing list