The dhcrelay service installed with dhcp doesn't work as advertised or as documented in the man page. Watching network traces it appears that dhcrelay picks up requests from the client, and then relays them to the server on a different interface. The server gets the request and responds, but dhcrelay doesn't seem to get the response, so it doesn't relay to the client. This actually doesn't seem to be really a Gentoo problem - more of a fundamental problem with dhcrelay itself. The man page tells you to do something like this: dhcrelay -i <interface> <dhcp_server> So, for instance, if I have a server with eth0 and eth1, where eth0 is on the segment with clients (for instance, 10.1.2.0/24, and eth1 is on the segment with the dhcp server (10.1.1.0/24. dhcp server is 10.1.1.1), I would launch as follows: dhcrelay -i eth0 10.1.1.1 sniffing the network, one can see requests from clients on eth0, and then the repeated requests to the server going out on eth1. The server logs the requests and responds, but dhcrelay doesn't seem to pick up the responses on eth1 to relay back to the clients on eth0. Searching around the internet, I see a very weird workaround mentioned in a lot of emails, telling that it should be launched like this: dhcrelay -i eth0 -i eth1 10.1.1.1 So I have to manually specify also the segment that is connected to the server. Some comments seemed to indicate that dhcrelay only bound to interfaces specified by the -i parameter, to listen for packets. This would tend to make sense because in the proper example above it doesn't seem to get the packets from the server even though the server is sending them. My problem: say for some reason I do NOT want dhcrelay listening on eth1 for requests? This seems only logical, because the server is listening on that segment anyway. There seems to be no way to actually make it work in this situation. Also, when I try to get it to listen on the server segment, I get a pile of looping repeat requests. It seems that dhcrelay is hearing it's own requests to the server and interpreting them as new client requests, and then relaying them again, which causes a vicious circle. For this reason, among others, I don't want it listening for new requests on the segment that the dhcp server is already listening on. Reproducible: Always Steps to Reproduce: 1. fill out /etc/conf.d/dhcrelay with the interface to listen for client requests 2. start /etc/init.d/dhcrelay Actual Results: clients do not get responses from dhcrelay because dhcrelay is not picking the responses up from the server Expected Results: dhcrelay should be listening for responses from the server on eth1 BUT NOT for client requests, and then should send the responses back to the clients on eth0 Well, it seems like this is a problem with the original software, and either no one uses dhcrelay or no one seems to have this requirement. Given that this is an official part of the ISC DHCP package, created by what seems to be the official body responsible for dhcp itself, it is surprising that this doesn't work right.
Not to add too much to this already long-winded item, but here's an item from the ISC DHCP list that describes the same problem, with a copy of a post from a developer agreeing that this is a real issue and basically that dhcrelay is broken. http://marc.theaimsgroup.com/?l=dhcp-server&m=112628037130885&w=2
Mass reassign wrt Bug 23718, maintainer being retired.
This is going to have to be fixed upstream unless anyone can submit a patch. We could add a post emerge message to the ebuild stating that dhcrelay is broken and reference this bug.
