DHCP relay problems with unicast DISCOVER and ACK packets

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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

On Aug 2, 2017, at 7:59 PM, Klemen Sladic <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DHCP relay problems with unicast DISCOVER and ACK packets

Klemen Sladic
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 <[hidden email]> 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

On Aug 2, 2017, at 7:59 PM, Klemen Sladic <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DHCP relay problems with unicast DISCOVER and ACK packets

Michael Lanski
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.

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?  

What is the mdl0 interface, and how is it connected in this scenario?  If it’s dropping the packet, it is the issue.



Michael Lanski
Director of Educational Services
DeepDive Networking, Inc
www.deepdivenetworking.com




On Aug 2, 2017, at 9:57 PM, Klemen Sladic <[hidden email]> wrote:

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 <[hidden email]> 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

On Aug 2, 2017, at 7:59 PM, Klemen Sladic <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: DHCP relay problems with unicast DISCOVER and ACK packets

Klemen Sladic
Yes, machine2 is routing the traffic without any relay. Relay is on machine1 only.
The DHCP server (Ubuntu) is directly connected to eth0 of machine2 ... with a cable.
mdl0 is our wireless interface, and since relay on machine1 is dropping ACKs, I do not believe mdl0 is dropping anything.

I wonder, should relay even see those ACKs since they can be directly routed?
Is there maybe a problem with next router/gid setting in packets?h

RegK



On Aug 3, 2017 15:47, "Michael Lanski" <[hidden email]> wrote:
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.

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?  

What is the mdl0 interface, and how is it connected in this scenario?  If it’s dropping the packet, it is the issue.



Michael Lanski
Director of Educational Services
DeepDive Networking, Inc
www.deepdivenetworking.com




On Aug 2, 2017, at 9:57 PM, Klemen Sladic <[hidden email]> wrote:

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 <[hidden email]> 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

On Aug 2, 2017, at 7:59 PM, Klemen Sladic <[hidden email]> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users


_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users
Loading...