Closed BearGFR closed 1 year ago
CyberShadow
commented
1 year ago dhcptest uses very simple networking, and should behave like any other UDP network program. I don't really know much about Windows, but I don't think that sort of thing would be specific to dhcptest.
You could try the --target option, which sends a more regular packet targeted at the specified IP address, instead of a less common broadcast packet.
BearGFR
commented
1 year ago I continued my examination and testing, and here is what I eventually found:
If I run dhcptest on a multi-homed system, the results are unpredictable unless I explicitly provide the –bind option and force it to an operational IPv4 address. What I discovered from more testing, is that on the systems where dhcptest was previously not working, the discover packet was being sent out using DHCP protocol, with a source address in APIPA format, from an IPv6 address???? Here is a wireshark screen capture:
From: Vladimir Panteleev @.> Sent: Saturday, August 19, 2023 1:44 AM To: CyberShadow/dhcptest @.> Cc: Robert Garrett @.>; Author @.> Subject: Re: [CyberShadow/dhcptest] Problem with failover clustering (Issue #36)
Closed #36https://github.com/CyberShadow/dhcptest/issues/36 as completed.
— Reply to this email directly, view it on GitHubhttps://github.com/CyberShadow/dhcptest/issues/36#event-10135506651, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGXLC3IWRNCABSOJ6VBTLSLXWBOD5ANCNFSM6AAAAAA3QE4YTY. You are receiving this because you authored the thread.Message ID: @.**@.>>
sjackson0109
commented
1 year ago Perhaps this info might help.I once had a windows 2012r2 pair of DNA servers, configured in failover mode.As it happens the first of the pair issued a dhcp lease but then the server had some network stability problems. Not enough for ping monitoring to trigger!Users of the client devices reported dozens of issues, typically a network dropout every hour. I confirmed the switch uplink to the firewall, and wan circuit were rock-solid (fping).Wire shark revealed the behaviour.DNS server 1 offered a lease inside an ACK packet.Windows clients perform a dhcp renew every hour, inspiteof the 8-hour lease in the server scope.With DNS server 1 being offline; you would expect dns server 2 to ACK the request for renewal, but infact it performs a DNAK (denial), hence the client looses it’s current ip-address. After 30 seconds the corny performs another dhcp-request, and the dns server 2 performs an offer via another ACK. The client got the same ip address it had in the first place.Very weird behaviour from a clustering perspective. Can understand why dhcptest software can’t see the packets you are expecting. On 19 Aug 2023, at 15:27, BearGFR @.***> wrote: I continued my examination and testing, and here is what I eventually found:
If I run dhcptest on a multi-homed system, the results are unpredictable unless I explicitly provide the –bind option and force it to an operational IPv4 address. What I discovered from more testing, is that on the systems where dhcptest was previously not working, the discover packet was being sent out using DHCP protocol, with a source address in APIPA format, from an IPv6 address????
Here is a wireshark screen capture:
@.***
From: Vladimir Panteleev @.***>
Sent: Saturday, August 19, 2023 1:44 AM
To: CyberShadow/dhcptest @.***>
Cc: Robert Garrett @.>; Author @.>
Subject: Re: [CyberShadow/dhcptest] Problem with failover clustering (Issue #36)
Closed #36https://github.com/CyberShadow/dhcptest/issues/36 as completed.
—
Reply to this email directly, view it on GitHubhttps://github.com/CyberShadow/dhcptest/issues/36#event-10135506651, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGXLC3IWRNCABSOJ6VBTLSLXWBOD5ANCNFSM6AAAAAA3QE4YTY.
You are receiving this because you authored the thread.Message ID: @.**@.>>
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
If the utility is run from a Windows Server instance that is also a member of a Windows failover cluster, one of two things is happening: If run from the instance that is NOT the current cluster "owner", the source IP address in the DISCOVER packet will be an APIPA address and not 0.0.0.0 If run from the instance that IS the current cluster "owner", the DISCOVER packet will not be sent at all.