DHCP Across Wireless Bridge
Glenn Satchell
glenn.satchell at uniq.com.au
Tue Dec 31 08:17:40 UTC 2013
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
>
More information about the dhcp-users
mailing list