DHCP relay problems with unicast DISCOVER and ACK packets

Thu Aug 3 02:57:24 UTC 2017

Hi.

This is a tcpdump on the mdl0 interface(192.168.192.2) on the client
machine with eth0(192.168.1.12):

192.168.1.12.bootpc > 192.168.0.27.bootps: BOOTP/DHCP, Request from
6c:ec:eb:b5:87:cd (oui Unknown), length 300
192.168.0.27.bootps > 192.168.1.12.bootpc: BOOTP/DHCP, Reply, length 327
192.168.1.12.bootpc > 192.168.0.27.bootps: BOOTP/DHCP, Request from
6c:ec:eb:b5:87:cd (oui Unknown), length 300
192.168.0.27.bootps > 192.168.1.12.bootpc: BOOTP/DHCP, Reply, length 327
192.168.1.12.bootpc > 192.168.0.27.bootps: BOOTP/DHCP, Request from
6c:ec:eb:b5:87:cd (oui Unknown), length 300
192.168.0.27.bootps > 192.168.1.12.bootpc: BOOTP/DHCP, Reply, length 327
192.168.1.12.bootps > 192.168.0.27.bootps: BOOTP/DHCP, Request from
6c:ec:eb:b5:87:cd (oui Unknown), length 300
192.168.0.27.bootps > 192.168.1.12.bootps: BOOTP/DHCP, Reply, length 341
192.168.1.12.bootps > 192.168.0.27.bootps: BOOTP/DHCP, Request from
6c:ec:eb:b5:87:cd (oui Unknown), length 300
192.168.0.27.bootps > 192.168.1.12.bootps: BOOTP/DHCP, Reply, length 341

So it looks like ACKs are comming back.
Running the relay with -d, I get:

Dropping request received on mdl0
Dropping request received on mdl0
Dropping request received on mdl0
Adding 15-byte relay agent option
Adding link selection suboption with addr: 192.168.1.12
Forwarded BOOTREQUEST for 6c:ec:eb:b5:87:cd to 192.168.0.27
Forwarded BOOTREPLY for 6c:ec:eb:b5:87:cd to 192.168.1.12
Adding 15-byte relay agent option
Adding link selection suboption with addr: 192.168.1.12
Forwarded BOOTREQUEST for 6c:ec:eb:b5:87:cd to 192.168.0.27
Forwarded BOOTREPLY for 6c:ec:eb:b5:87:cd to 192.168.1.12

It is probably ok it is dropping unicast packets, though.
But why they don't reach the et0?

Forwarding is enabled on both ports, and I can ping the server,
so unicast connection works.

Thank you very much for any assistance on this ;)

RegK

On Thu, Aug 3, 2017 at 2:19 PM, Michael Lanski <mlanski at comcast.net> wrote:

> 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
>
> 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
>
>
>
> _______________________________________________
> 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/20170803/a533f818/attachment-0001.html>