Installed 'new' Netgear N300 (DGN2200-100UKS model number)

Day 1: Install

Changed router IP to 192.168.1.1

Setup DHCP range to 192.168.1.50 - 100

All clients connected and working, 4 Pc's connected via LAN (separate switch). 1 laptop and 2 mobiles connected on Wifi, all on DHCP. 3 static devices - network laser & 2 print servers for dot matric printers. All static addresses out of DHCP range.

Day 2: Problems start

One of the LAN connected PC's (Windows 7) reports an IP address in the 192.168.0.x subnet (mask is 255.255.255.0) so would not connect. 'stop gap' measure (as I'm not on site), was to set it with a static IP (192.168.1.155 - out of the DHCP range, alongside the other static addresses). Everything else still working ok.

Day 3: Problems continue

Remaining LAN connected Windows Windows 7 PC reports an invalid IP address out of the subnet and won't connect. Set it as static (like the first Win 7 PC) and check the DHCP range is correct within router (it is). Reboot router. Wifi client devices also cannot connect, wrong IP's again. Change Win7 Laptop on Wifi to a static address as a work around.

Remaining DHCP Wifi clients (2 mobiles) cannot connect so need DHCP working. There will be more DHCP connected mobile devices in the near future as seasonal people return to work. Remaining DHCP LAN client PC's (2 Windows XP's) have been totally unaffected by this and continue to have correct IP's.

Running whatever base firmware the router came with - so will update this when next on site.

Troubleshooting

There is mention of the RIP version having an impact on clients connecting on DHCP so I will be changing that shortly. Probably another router reboot as part of the setting change.

I drew a complete blank running netsh dhcp show server (command not found) to verify what DHCP server clients were connected - because the client needs to be connected on DHCP to run it? And I cannot do that as I can't then be connected to the client PC remotely...

Are there other DHCP commands I can run - I'm ideally looking for one which will list available DHCP servers as I'm convinced DHCP is running on something else (that I'm unaware of) and dishing out these 192.168.0.x addresses.

Well first if you use 192.168.1.x and 192.168.0.x you need to adjust your subnet to 255.255.0.0 as 192.168.1.x and 192.168.0.x are now to separate subnets and speciifying 255.255.255.0 would tell the client to only look at the last octet [the very last .x] specifying 255.255.0.0 would tell it look at both .x.x on the end of 192.168.x.x.

REALLY you should turn OFF the DHCP in the new router set it's IP as an IP in the range of the original router [if the original router is the 192.168.1.1 then set second router to a LAN IP of 192.168.1.x [not WAN LAN I'll explain]

THEN make sure you connect a LAN cable from ANY LAN port on the first router to ANY LAN port on the 2nd [if you used the WAN on the 2nd then you will get double NAT'd and need to specify any port forwards for any clients on the 2nd router on both the first AND 2nd router before they would work. That gets crazy right.

If you keep the second router on a LAN port of the first then what happens is any DHCP requests would pass through to the first router you have and work as you would expect SO.

Easiest thing is to set LAN IP of second router to something within the network of the first, turn off DHCP on 2nd router [this stops any conflicts and other issues], and connect them with a cable from a LAN port of router 1 to a LAN port of router 2. You will want to also kill the Wi-Fi AP running on the first if they are close together since you prolly are wanting to use the newer router as a Wi-Fi AP I bet and 2 radios that close can actually slow things down if both competing with each other but it's not required just a note if you notice WiFi connect issues.

Ifd there is any other device in the network handing out DHCP ack in the 192.168.0.x range then you have at least two options:

1. Snoop all traffic (e.g. using wireshark),


2. Or do it the lazy way: Let a client connect to the rogue DHCP server. Most of the time this also sets the default gateway the the same IP as the DHCP server. You then have a suspect IP, can lookup ARP, can trace which network port it is one, ...

The last is easiest with managed switches, but you could also ping the target device to see which ports lights up.

Personal ramblings / stories:

I have had this problem twice at work. Once when someone brought a wireless accesspoint/router/switch from home to use as a switch and left on unintended functionality, and once when people played with virtualisation software and enabled its DHCP server on the bridged network rather than on the host-only network.