<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Ok, the traces prove (although we could already tell from syslog messages) that the server is not at fault.  It sends the ACK, and your machine receives it.</div><div class=""><br class=""></div><div class="">I’m a bit confused, however, by your original diagram, and the responses.  You list “machine 1” and “machine 2”.  Are you using one system to somehow route and/or bridge to the other?  You show some wireless in the middle of 2 systems, then the DHCP server.  Is there a router between 2 networks (192.168.0.x and 192.168.1.x)?  Is it the relay?  </div><div class=""><br class=""></div><div class="">What is the mdl0 interface, and how is it connected in this scenario?  If it’s dropping the packet, it is the issue.</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Michael Lanski<br class="">Director of Educational Services<br class="">DeepDive Networking, Inc<br class=""><a href="http://www.deepdivenetworking.com" class="">www.deepdivenetworking.com</a></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline">
</div>

<br class=""><div><blockquote type="cite" class=""><div class="">On Aug 2, 2017, at 9:57 PM, Klemen Sladic <<a href="mailto:gosturnca@gmail.com" class="">gosturnca@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><span style="font-family:monospace,monospace" class="">Hi.<br class=""><br class=""></span></div><span style="font-family:monospace,monospace" class="">This is a tcpdump on the mdl0 interface(192.168.192.2) on the client<br class="">machine with eth0(192.168.1.12):<br class=""><br class="">192.168.1.12.bootpc > 192.168.0.27.bootps: BOOTP/DHCP, Request from 6c:ec:eb:b5:87:cd (oui Unknown), length 300<br class="">192.168.0.27.bootps > 192.168.1.12.bootpc: BOOTP/DHCP, Reply, length 327<br class="">192.168.1.12.bootpc > 192.168.0.27.bootps: BOOTP/DHCP, Request from 6c:ec:eb:b5:87:cd (oui Unknown), length 300<br class="">192.168.0.27.bootps > 192.168.1.12.bootpc: BOOTP/DHCP, Reply, length 327<br class="">192.168.1.12.bootpc > 192.168.0.27.bootps: BOOTP/DHCP, Request from 6c:ec:eb:b5:87:cd (oui Unknown), length 300<br class="">192.168.0.27.bootps > 192.168.1.12.bootpc: BOOTP/DHCP, Reply, length 327<br class="">192.168.1.12.bootps > 192.168.0.27.bootps: BOOTP/DHCP, Request from 6c:ec:eb:b5:87:cd (oui Unknown), length 300<br class="">192.168.0.27.bootps > 192.168.1.12.bootps: BOOTP/DHCP, Reply, length 341<br class="">192.168.1.12.bootps > 192.168.0.27.bootps: BOOTP/DHCP, Request from 6c:ec:eb:b5:87:cd (oui Unknown), length 300<br class="">192.168.0.27.bootps > 192.168.1.12.bootps: BOOTP/DHCP, Reply, length 341<br class=""><br class=""></span></div><span style="font-family:monospace,monospace" class="">So it looks like ACKs are comming back.<br class=""></span></div><span style="font-family:monospace,monospace" class="">Running the relay with -d, I get:<br class=""><br class="">Dropping request received on mdl0<br class="">Dropping request received on mdl0<br class="">Dropping request received on mdl0<br class="">Adding 15-byte relay agent option<br class="">Adding link selection suboption with addr: 192.168.1.12<br class="">Forwarded BOOTREQUEST for 6c:ec:eb:b5:87:cd to 192.168.0.27<br class="">Forwarded BOOTREPLY for 6c:ec:eb:b5:87:cd to 192.168.1.12<br class="">Adding 15-byte relay agent option<br class="">Adding link selection suboption with addr: 192.168.1.12<br class="">Forwarded BOOTREQUEST for 6c:ec:eb:b5:87:cd to 192.168.0.27<br class="">Forwarded BOOTREPLY for 6c:ec:eb:b5:87:cd to 192.168.1.12<br class=""></span><div class=""><div class=""><div class=""><span style="font-family:monospace,monospace" class=""><br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class="">It is probably ok it is dropping unicast packets, though.<br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class="">But why they don't reach the et0?<br class=""><br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class="">Forwarding is enabled on both ports, and I can ping the server,<br class="">so unicast connection works.<br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class=""><br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class="">Thank you very much for any assistance on this ;)<br class=""><br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class="">RegK<br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class=""><br class=""><br class=""></span></div><div class=""><span style="font-family:monospace,monospace" class=""><br class=""></span><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Aug 3, 2017 at 2:19 PM, Michael Lanski <span dir="ltr" class=""><<a href="mailto:mlanski@comcast.net" target="_blank" class="">mlanski@comcast.net</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">Michael Lanski</div><div class="">Director of Educational Services</div><div class="">DeepDive Networking, Inc</div><div class=""><a href="http://www.deepdivenetworking.com/" target="_blank" class="">www.deepdivenetworking.com</a></div>


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