Problems if certain virtual adapters exist.

[BearGFR]

I wanted to use this tool to create an automated script that runs on a timer to test my DHCP server(s) and take remedial action/generate email alerts if issues are found. My configuration is admittedly somewhat out of the ordinary. I have two Windows Server 2019 instances, each one running as a virtual machine on two different hardware platforms, each also running the Server 2019 HyperVisor. There are DHCP servers running on each of the HyperVisor images (real machines) in a DHCP failover configuration. The two virtual Servers are also configured in a Windows Failover Cluster, which is at least part of the problem I'm about to describe. I wanted to use dhcptest inside an automation script, running on a timer, to verify DHCP servers are working and take action if not. What I think is happening, is that dhcptest is perhaps by default sending its DISCOVER packets out over the first IP interface it finds, which in my case just happens to be the virtual adapter that Failover Clustering uses. This adapter will always have an APIPA address in subnet 169.254/16 so that's what goes out from the two VM's. I think when the Hypervisor sees those packets, it drops/blocks them because of those APIPA addresses. I say this because via Wireshark I can see the packets going out on on the VM side, but they never "arrive" in Wireshark on the Hypervisor side. I'm not sure if this is a solvable situation, but if it is, I'd certainly appreciate it. Thanks.

[CyberShadow]

Have you tried using --bind to specify the interface to use?

The emulated virtualized network may also be dropping packets because of the fictional MAC address; have you tried using --mac?

[BearGFR]

I just did, but it still doesn't work.

dhcptest --mac 00:15:5D:02:EB:00 --bind 192.168.2.33 <-- both mac and ip of the 'correct' interface dhcptest v0.7 - Created by Vladimir Panteleev https://github.com/CyberShadow/dhcptest Run with --help for a list of command-line options.

Error while attempting to bind socket: Unable to bind socket: The requested address is not valid in its context. Replies will not be visible. Use a packet capture tool to see replies, or try re-running the program with more permissions. Type "d" to broadcast a DHCP discover packet, or "help" for details.

..and...

dhcptest --mac 00:15:5D:02:EB:00 dhcptest v0.7 - Created by Vladimir Panteleev https://github.com/CyberShadow/dhcptest Run with --help for a list of command-line options.

Listening for DHCP replies on port 68. Type "d" to broadcast a DHCP discover packet, or "help" for details. d Sending packet: op=BOOTREQUEST chaddr=00:15:5D:02:EB:00 hops=0 xid=DBB489BA secs=0 flags=8000 ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file= 1 options: 53 (DHCP Message Type): discover

[CyberShadow]

Unable to bind socket: The requested address is not valid in its context.

According to https://stackoverflow.com/questions/38958233/the-requested-address-is-not-valid-in-its-context-error , that means that the specified IP address is not actually assigned to any interface.

Do you see it in ipconfig?

[BearGFR]

Yes, it's a static IP, assigned to the active adapter. See attached image

[CyberShadow]

I really have no idea why --bind isn't working, then...

[CyberShadow]

I am going to close this because it doesn't look actionable from my side, but we can reopen if more information emerges.