I recently helped an end user troubleshoot an access control module that stopped communicating with the network. The NIC likely failed. The only issue was that the new module had to be set to the same IP address as the old module , but that IP was unknown because the old module was broken. There was also no access to the router.
The information we had:
- A public IP for the broken module 173.x.x.x:8089
- A public IP for a working module 173.x.x.x:8090
- The LAN IP of an existing working module 192.168.0.26 and the MAC address
At first glance, it was evident that the IP address was public, forwarding to port 8089 on the LAN, so the replacement module would have to be set to the same private IP as before because we didn’t have access to the router to check the port forward settings. The old module was not functioning, so we could not lookup the target IP.
Troubleshooting steps taken:
- Plug a laptop into the wire that was plugged into the module, just to see what network we connect to and if DHCP is active. The result was a 192.168.1.178 address which was a different network than the working module was on (192.168.0.26).
- Ask the user to check their IP settings. Computer NIC was set to a static IP…set to DHCP. Pulled an address on the same 192.168.0.X network. Could then ping the .26 address, as well as the default gateway.
- Navigate to the default gateway address to check if we can login to the router to check which IP is mapped to port 8089. Router UN and PW unknown.
- Run advanced IP scanner to see if the IP and MAC of the old module were still in the ARP table. They were not.
- Take an educated guess that perhaps the old module was at either 192.168.0.25 or .27 because the working module is at .26. First ping .25 to make sure the address is not in use. It was not.
- Set module to .25 address and then rechecked the web address 173.x.x.x:8089 remotely. Module is now reachable.
This a real-world example of network troubleshooting that may be encountered in the field or remotely. In this case, the router was taken over by our company, but we did not yet have the old UN and PW in order to login to the router. We took an educated guess that the old module IP address was likely adjacent to the working module IP, made sure the IP we were going to use was not active in order to avoid an IP conflict, and lucked out in this scenario.