DHCP relay problems with unicast DISCOVER and ACK packets

[Michael Lanski]

One note:  DHCP renews, as you mentioned, are unicast, so the communication path is between the client and server.  No relay would be in use here.  The fact that syslog shows “via usb1” proves it’s not trying to send it via the relay, but out the “usb1” interface, as a unicast to the client.

Since the DHCP server must be able to communicate with all the clients directly, my first guess is that you have a firewall/router access-list in the way so that the UDP/DHCP packets can’t make it from the DHCP server to the client?  Have you verified your access-lists?  Have you traced the packet to see what it does get to?  Does your router forward it, or drop it?

Michael Lanski
Director of Educational Services
DeepDive Networking, Inc
www.deepdivenetworking.com <http://www.deepdivenetworking.com/>
> On Aug 2, 2017, at 7:59 PM, Klemen Sladic <gosturnca at gmail.com> wrote:
> 
> Hi.
> 
> I am trying to relay DHCP requests. When the client broadcasts
> DISCOVER everything looks ok. It gets the IP etc.
> But on RENEW, when unicast DISCOVER is sent, it is received by the
> server, the server replies with ACK, but the ACK does not get back
> to the client, it get dropped by the relay.
> I have tried lots of different interface switches with no success.
> 
> My setup: ISC DHCP 4.3.5 on Linux.
> Network looks like:
> <Machine1>---wireless---<Machine2>---Eth---<DHCP server>
> 
> eth0 192.168.1.12 - DHCP obtained IP
> | Machine1
> |DHCP client unit - it has a direct route to the DHCP server!
> | running: dhcrelay -U eth0 -iu mdl0 192.168.0.27
> mdl0 192.168.192.2 - wireless interface
> |
> ...
> wireless connection
> ...
> |
> mdl0 192.168.192.1 - wireless interface
> | Machine2
> | Unit just routing the traffic - NO RELAY here.
> eth0 192.168.0.1
> |
> Eth cable connection to DHCP server
> |
> eth0 192.168.0.27 DHCP server
> 
> 
> On RENEW I see:
> 
> CLIENT (NOTHING IS HAPPENING ON UNICAST REQUESTS!):
> dhclient: DHCPREQUEST on eth0 to 192.168.0.27 port 67
> dhclient: DHCPREQUEST on eth0 to 192.168.0.27 port 67
> dhclient: DHCPREQUEST on eth0 to 192.168.0.27 port 67
> dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
> dhclient: DHCPACK from 192.168.1.12
> dhclient: bound to 192.168.1.12 -- renewal in 17 seconds.
> 
> SERVER:
> dhcpd[3853]: DHCPREQUEST for 192.168.1.12 from 6c:ec:eb:b5:87:cd via usb1
> dhcpd[3853]: DHCPACK on 192.168.1.12 to 6c:ec:eb:b5:87:cd via usb1
> dhcpd[3853]: DHCPREQUEST for 192.168.1.12 from 6c:ec:eb:b5:87:cd via usb1
> dhcpd[3853]: DHCPACK on 192.168.1.12 to 6c:ec:eb:b5:87:cd via usb1
> dhcpd[3853]: DHCPREQUEST for 192.168.1.12 from 6c:ec:eb:b5:87:cd via usb1
> dhcpd[3853]: DHCPACK on 192.168.1.12 to 6c:ec:eb:b5:87:cd via usb1
> dhcpd[3853]: DHCPDISCOVER from 6c:ec:eb:b5:87:cd via 192.168.1.12
> dhcpd[3853]: DHCPOFFER on 192.168.1.12 to 6c:ec:eb:b5:87:cd via 192.168.1.12
> dhcpd[3853]: DHCPREQUEST for 192.168.1.12 (192.168.0.27) from 6c:ec:eb:b5:87:cd via 192.168.1.12
> dhcpd[3853]: DHCPACK on 192.168.1.12 to 6c:ec:eb:b5:87:cd via 192.168.1.12
> 
> Does anyone has any idea why this is happening?
> 
> RegK
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170802/4bcf991e/attachment.html>