DHCP relay problems with unicast DISCOVER and ACK packets

[Klemen Sladic]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20170803/73c14251/attachment.html>