Windows 7 Client flooding network with DHCP requests. Not setting IP

Question

I have a small network, with 15 workstations, SAMBA AD, and a bunch of Virtualized linux servers. All the workstations, and servers are on the same subnet.

All workstations are running Windows 7 Pro

Both my Samba 4 DC, and ISC-DHCP-SERVER are running on the same virtualized host.

Most, if not all workstations have DHCP reservations configured.

One of my workstations will not acquire a dhcp address. When I enable the adapter, my DHCP Server's syslog reports the following: ( I have tried removing the dydns scripts, and it did not make any difference, so please disregard those messages.)

Jan  6 03:47:21 frfdc dhcpd[984]: DHCPREQUEST for 192.168.1.249         (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPACK on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPDISCOVER from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPOFFER on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: Commit: IP: 192.168.1.249 DHCID: 1:0:23:24:a1:cd:80 Name: FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[0] = /etc/dhcp/bin/dhcp-dyndns.sh
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[1] = add
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[2] = 192.168.1.249
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[3] = 1:0:23:24:a1:cd:80
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[4] = FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : Getting new ticket, old one has expired
Jan  6 03:47:21 frfdc sh[984]: kinit: Permission denied while getting initial credentials
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : dhcpd kinit for dynamic DNS failed
Jan  6 03:47:21 frfdc dhcpd[984]: execute: /etc/dhcp/bin/dhcp-dyndns.sh exit status 256
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPREQUEST for 192.168.1.249 (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPACK on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPDISCOVER from 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: DHCPOFFER on 192.168.1.249 to 00:23:24:a1:cd:80 via eth0
Jan  6 03:47:21 frfdc dhcpd[984]: Commit: IP: 192.168.1.249 DHCID: 1:0:23:24:a1:cd:80 Name: FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[0] = /etc/dhcp/bin/dhcp-dyndns.sh
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[1] = add
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[2] = 192.168.1.249
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[3] = 1:0:23:24:a1:cd:80
Jan  6 03:47:21 frfdc dhcpd[984]: execute_statement argv[4] = FRF-M014-PC
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : Getting new ticket, old one has expired
Jan  6 03:47:21 frfdc sh[984]: kinit: Permission denied while getting initial credentials
Jan  6 03:47:21 frfdc dhcpd: 06-01-18 03:47:21 [dyndns] : dhcpd kinit for dynamic DNS failed
Jan  6 03:47:21 frfdc dhcpd[984]: execute: /etc/dhcp/bin/dhcp-dyndns.sh exit status 256

I appear to be getting flooded with 10 requests per second for this workstation. Eventually Windows times out, and assigns itself a 169.x.x.x address, and quits.

Any insights/suggestions would be most welcome.

On the workstation I have tried: Updating drivers. Installing bare OS. Disabling wireless NIC. Applying a registry setting "DhcpConnEnableBcastFlagToggle to 1" in HKLM-System-Current Control Set-Services-TCPIP-Parameters-interfaces-GUID.

On the Server I have tried updating the DHCP server. I am now at 3.3-5ubuntu12.7 I have investigated different delay settings, but they do not seem to help.

dhcpd.conf below: (Other reservations removed)

default-lease-time 600;
max-lease-time 7200;

authoritative;

subnet 192.168.1.0 netmask 255.255.255.0 {
  option subnet-mask 255.255.255.0;
  option broadcast-address 192.168.1.255;
  option time-offset 0;
  option routers 192.168.1.1;
  option domain-name "CHANGED.local";
  option domain-name-servers 192.168.1.19;
  option netbios-name-servers 192.168.1.19;
  option ntp-servers 192.168.1.19, 192.168.1.250;


host FRF-M014-PC.FRFCanada.local{
  hardware ethernet 00:23:24:a1:cd:80; 
  fixed-address 192.168.1.249; 
}

pool {
  max-lease-time 1800; # 30 minutes
  range 192.168.1.150 192.168.1.199;
  }
}

Update: Jan 7, 2018 12:40 I do not see anything the event logs on the client that looks relevant. I have tried changing the reservation IP to 192.168.1.6 - The client still floods the dhcp server for about 30 seconds, but does eventually accept the IP. I am searching for a possible duplicate of 192.168.1.249 - but have not been able to find one as of yet. It's Sunday, and no-one else is in the office, so that might be part of the reason why. I have also added the suggested registry key.

Update: Jan 7, 2018 12:40 I have celebrated too soon. I rebooted the client, and it is no longer accepting the IP

Update Jan 7, 2018 13:45 After 15 minutes of requesting an IP, the client eventually accepted the IP. Log captured below:

Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPREQUEST for 192.168.1.6 (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPACK on 192.168.1.6 to 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPDISCOVER from 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPOFFER on 192.168.1.6 to 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: Commit: IP: 192.168.1.6 DHCID: 1:0:23:24:a1:cd:80 Name: FRF-M014-PC
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[0] = /etc/dhcp/bin/dhcp-dyndns.sh
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[1] = add
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[2] = 192.168.1.6
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[3] = 1:0:23:24:a1:cd:80
Jan  7 13:42:05 frfdc dhcpd[1693]: execute_statement argv[4] = FRF-M014-PC
Jan  7 13:42:05 frfdc dhcpd: 07-01-18 13:42:05 [dyndns] : Getting new ticket, old one has expired
Jan  7 13:42:05 frfdc sh[1693]: kinit: Permission denied while getting initial credentials
Jan  7 13:42:05 frfdc dhcpd: 07-01-18 13:42:05 [dyndns] : dhcpd kinit for dynamic DNS failed
Jan  7 13:42:05 frfdc dhcpd[1693]: execute: /etc/dhcp/bin/dhcp-dyndns.sh exit status 256
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPREQUEST for 192.168.1.6 (192.168.1.19) from 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:05 frfdc dhcpd[1693]: DHCPACK on 192.168.1.6 to 00:23:24:a1:cd:80 via eth0
Jan  7 13:42:08 frfdc dhcpd[1693]: DHCPINFORM from 192.168.1.6 via eth0
Jan  7 13:42:08 frfdc dhcpd[1693]: DHCPACK to 192.168.1.6 (00:23:24:a1:cd:80) via eth0

Update Jan 7, 2018 14:45

Changed NIC, Updated reservation with new NIC's MAC. Same result.

Update Jan 8, 2018 9:45

Update Jan 9, 2018

I have acquired an outage window for Jan 13/14. No more updates until the 15'th

Update Jan 14, 2018 I tried rebooting the switch, and physical server. Still no change. I then assigned the server it's own physical NIC / Switch port. Still no change. I then reviewed the switch configuration, and re-applied the port settings to the port being used, and the flood seems to have stopped. I am not yet convinced, and will monitor for a couple of days.

Your wireshark capture looks odd. There are 6 distint DHCP conversations (based on the transaction ID) and the DHCP offer is being sent to a particular ip address (192.168.1.6), when it should be going to 255.255.255.255 as the client shouldn't yet have an ip address. That behavior should only be seen during the T1 phase (renewal). Do you have an alternate ip address configured on the NIC of the client? — joeqwerty, Jan 08 '18 at 15:24
There are no alternative addresses configured. That is just a small snippet. There are 600 requests per minute from that specific client. It is possible that the client is trying to renew at the time, because, i just disable the NIC on the client. start the capture, and then re-enable the NIC. After a long time (10 minutes sometimes) it does eventually grab an IP — Skye Bowen, Jan 08 '18 at 16:43
During the renewal phase (T1) traffic is unicast directly between the ip address of the server and the existing DHCP leased ip address of the client. During the rebinding phase (T2) the client will return to the INIT phase and use broadcast to contact any DHCP server. Your trace seems to show both behaviors occurring simultaneously, which is very odd. I'm unable to replicate this behavior in a lab environment. — joeqwerty, Jan 08 '18 at 20:34

score 3 · Answer 1 · answered Jan 07 '18 at 01:39

3

Seem to me a bad NIC in the workstation.

Try a firmware update and if it still don’t work change the NIC.

answered Jan 07 '18 at 01:39

yagmoth555

16,300
4
26
48

Thanks,Please see new details posted. I changed the NIC, updated reservation. Same behavior. – Skye Bowen Jan 07 '18 at 20:45
@SkyeBowen Please do a wireshark from the client side if you can to continue the diagnostic, and show us it. – yagmoth555 Jan 08 '18 at 01:52
@SkyeBowen Thanks for the wireshark. The computer never receive the last confirmation from the DHCP server. Wireshark inbound is seen before the firewall, thus it's not a computer firewall that block the packet. (Outbound in wireshark is after the firewall). Try another switch port, seem a ARP problem with the switch maybe (or just a port problem) – yagmoth555 Jan 08 '18 at 14:54
Thanks, I have tried swapping ports. Both the server, and client are plugged into the same switch. No special VLAN configs on either port. I am using a Ubiquiti US-48-750w switch. (if that makes any difference) – Skye Bowen Jan 08 '18 at 15:13
@SkyeBowen Do you got a maintenance windows, to be able to use like another switch and plugging the server and computer on it to rule out the switch ? – yagmoth555 Jan 08 '18 at 15:15

score 2 · Answer 2 · answered Jan 06 '18 at 20:13

Based on the offer -> commit it appears like DHCP server is working; so for some reason the client isn't accepting the issued IP.

Is there something else using that IP; windows will use ARP to identify any conflicting mac/IP bindings for an IP address before it binds it to it's own interface.

Easiest test is to try another IP; alternatively you can kill duplicate address detection via registry:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

DWORD  ArpRetryCount = 0

score 1 · Answer 3 · answered Jan 07 '18 at 05:46

1

Did you check the Windows events for any NIC issues? I found the below link on MS support site.

https://support.microsoft.com/en-us/help/325487/advanced-network-adapter-troubleshooting-for-windows-workstations

answered Jan 07 '18 at 05:46

Vignesh SP

129
10

Yes, I didn't find any issues. – Skye Bowen Jan 23 '18 at 23:00

score 0 · Answer 4 · answered Jan 08 '18 at 16:46

0

Have you tried using a different Ethernet cable/connection into the nic? Have you tried disabling ipv6 on the nic? Have you turned off the firewall on the machine and checked again?

answered Jan 08 '18 at 16:46

qore5

371
1
2
6

Have you tried using a different Ethernet cable/connection into the nic? - Yes Have you tried disabling ipv6 on the nic? - Yes Have you turned off the firewall on the machine and checked again? -Yes – Skye Bowen Jan 08 '18 at 16:54
I have also known power supplies to cause issues like this. You could try swapping a power supply from a good machine into that one. A bit of work but could work and diagnose the issue. – qore5 Jan 08 '18 at 16:56
Disabling IPv6 is counter to Microsoft's best practice and guidance and is never a solution to any problem... especially this one. – joeqwerty Jan 10 '18 at 03:20

Windows 7 Client flooding network with DHCP requests. Not setting IP

4 Answers4