Bug 36620

After investigating further, I found the problem wasn't related to the kernel 
version, but rather due to my ipchains firewall not letting packets addressed 
to 255.255.255.255 through.

But, I don't believe I should have had to change my firewall settings. Why is 
dhcp-2.0pl5 built to use "socket" instead of "LPF" (Linux Packet Filter) as 
before? From what I understand, "socket" is only meant to be used with 2.0.x 
kernels. So this looks like a "configure" error to me.

Same problem here. I have three network interfaces (eth0, eth1, eth2). The last
one is wireless. dhcpd worked fine until I upgraded to 7.1. Then it stopped
working on the wireless interface. Request packets were arriving (I checked with
tcpdump) but no answer was given, even with the firewall down. Downgrading
solved the problem. 

The startup message of the new (non working) version is 

May  4 09:27:12 dina dhcpd: Listening on Socket/eth2/192.168.0.128
May  4 09:27:12 dina dhcpd: Sending on   Socket/eth2/192.168.0.128
May  4 09:27:12 dina dhcpd: Listening on Socket/eth1/10.0.0.0
May  4 09:27:12 dina dhcpd: Sending on   Socket/eth1/10.0.0.0
May  4 09:27:12 dina dhcpd: Listening on Socket/eth0/192.168.0.0
May  4 09:27:12 dina dhcpd: Sending on   Socket/eth0/192.168.0.0
May  4 09:27:12 dina dhcpd: Listening on Socket/eth2/192.168.0.128
May  4 09:27:12 dina dhcpd: Sending on   Socket/eth2/192.168.0.128
May  4 09:27:12 dina dhcpd: Listening on Socket/eth1/10.0.0.0
May  4 09:27:12 dina dhcpd: Sending on   Socket/eth1/10.0.0.0
May  4 09:27:12 dina dhcpd: Listening on Socket/eth0/192.168.0.0
May  4 09:27:12 dina dhcpd: Sending on   Socket/eth0/192.168.0.0
May  4 09:27:12 dina dhcpd: dhcpd startup succeeded

The old one:


May  4 09:40:55 dina dhcpd: Listening on LPF/eth2/00:40:05:de:c8:5c/192.168.0.128
May  4 09:40:55 dina dhcpd: Sending on   LPF/eth2/00:40:05:de:c8:5c/192.168.0.128
May  4 09:40:55 dina dhcpd: Listening on LPF/eth1/00:60:08:ab:c3:9a/10.0.0.0
May  4 09:40:55 dina dhcpd: Sending on   LPF/eth1/00:60:08:ab:c3:9a/10.0.0.0
May  4 09:40:55 dina dhcpd: Listening on LPF/eth0/00:01:02:f3:58:ab/192.168.0.0
May  4 09:40:55 dina dhcpd: Sending on   LPF/eth0/00:01:02:f3:58:ab/192.168.0.0
May  4 09:40:55 dina dhcpd: Sending on   Socket/fallback/fallback-net
May  4 09:40:55 dina dhcpd: Listening on LPF/eth2/00:40:05:de:c8:5c/192.168.0.128
May  4 09:40:55 dina dhcpd: Sending on   LPF/eth2/00:40:05:de:c8:5c/192.168.0.128
May  4 09:40:55 dina dhcpd: Listening on LPF/eth1/00:60:08:ab:c3:9a/10.0.0.0
May  4 09:40:55 dina dhcpd: Sending on   LPF/eth1/00:60:08:ab:c3:9a/10.0.0.0
May  4 09:40:55 dina dhcpd: Listening on LPF/eth0/00:01:02:f3:58:ab/192.168.0.0
May  4 09:40:55 dina dhcpd: Sending on   LPF/eth0/00:01:02:f3:58:ab/192.168.0.0
May  4 09:40:55 dina dhcpd: Sending on   Socket/fallback/fallback-net
May  4 09:40:55 dina dhcpd: dhcpd startup succeeded

I came across the problem also if you download the source for the version 
2.0pl5 from www.isc.org and compile this it also works, this seems to be a 
problem the the rpm in which it is distributed.

I had the same problem with a fresh RedHat 7.1 installation. 
No firewall configured. The tcpdump shows all dhcp requests and no
responses.

After a whole afternoon trying to make it work I gave up and downgraded
to dhcp-2.0-12.i386.rpm (this version is fine).
BTW, I tried the last dhcp from rawhide and it doesn't work too.

It's amazing that a serious issue like this, opened at April did not get
any redhat response till today. Where's redhat QA?

Apologies for the unresponsiveness of the previous dhcp packager...
Unfortunately I'm not able to reproduce the problem, and the report is sort of
suspect because of the original firewall thing (it's entirely reasonable to
expect people to fix previously undiscovered bugs in their firewalls...)

Ideas anyone?

It's hard to believe you couldn't reproduce, because I couldn't make it work!
Not even once! :)

My guess is about LPF x Socket. I haven't try downloading the
source but there must be a compiling option somewhere 
(like configure --without-xxxx?) to choose the method it use
for listening. 

Isn't possible to turn back to the old LPF method?

If you look at the spec file and source tree, you will see there is no
configuration to be changed...

If I download ftp://ftp.isc.org/isc/dhcp/dhcp-2.0pl5.tar.gz and compile it 
using the defaults, I get a dhcpd binary that uses LPF.

Why is LPF "wrong", what other options are available, and how are they selected?

Also, if you aren't using the 2.4 kernel, that could explain the problems,
"don't do that". In low-level programs there are sometimes compile time options
that depend on knowing which kernel is targetted.

Some ideas, anyways...

An "LPF" binary is produced when I compile dhcp-2.0pl5.tar.gz with the 
defaults, on *either* a 2.2.19 or 2.4.2 system.

Now having said that, I think I see the bug now with the RPM. Try building the 
source RPM and watch closely. You'll notice:

"-DLINUX_MAJOR=MajorVersion -DLINUX_MINOR=MinorVersion"

Using valid numbers there would help :)

I have the exact same problem.  Use the RH 7.1 package and it just doesn't
work.  No firewall.  tcpdump shows requests arriving, but no responses. 
Requests are arriving on / should be going out eth1.  Downgrading to the
packages that shipped with RH 7.0 worked, but doesn't allow me to constrain the
IP assigned based on the ethernet address.

Hi,

I recently built dhcp-3.0 into rawhide - I am betting this problem is fixed by
it. Feel free to reopen the bug if not.

dhcp-3.0 seems to be gone from rawhide, apparently replaced with the old, 
broken dhcp-2.0pl5-8 package.

So, reopening...

That's the, uh, other rawhide.

The 3.0 package isn't gone, just deferred from the current line of development
due to compatibility concerns. It will reappear eventually, trust me.