Step 5: Test the network configuration

Before moving on to Part 3: setting up the development server, we need to confirm that each device connected to the local network can “see” the development server and that the development server can “see”

1. Ping the development server from itself

   I’m not sure how useful this is, but what the heck, at least you can confirm that the development server’s Network Interface Card (NIC) is operating with the static IP address that you’ve assigned to it.

   At the command prompt, on the development server type:

   C:\>ping 192.168.0.200

   Press Enter,

   

2. Ping networked devices from the development server

   From the development server, ping the IP address of each device connected to your local network including mobile devices. Here ’s an example of pinging the netbook from the development server:

   At the command prompt, type:

   C:\>ping 192.168.0.199

   Press Enter.

   

   Woo-hoo! The development server can see the netbook. Well that’s a good sign, now ping the remaining networked devices from the development server.

3. Ping the development server from networked devices

   Once you can ping all the networked devices from the development server, see if you can ping the development server from each connected device. Sadly, mobile devices require an app to ping other devices. Horrors, let’s not do that. Instead, in Part 3, Step 2[LINK] we’ll test the connection between a mobile device and the development server by serving up a simple web page.

   Here’s an example of pinging the development server from the netbook which is running Linux:

   From the terminal, type:

   $ ping 192.168.0.200

   Press Enter.

   

   Yup, the netbook has successfully pinged the server. Pinging in Linux will go on forever. Stop the process by pressing Ctrl+C.

   In this example, pinging the development server from the laptop was unsuccessful—need to find out why. Hmm…

   

4. When requests time out

   If, heaven forbid, your ping-fest isn’t entirely fruitful, here are a few things you can try to exorcise the network gremlins:

   1. Confirm that each device can access the Internet via the modem. If it can, you’re off to a great start. At least your devices are having two way conversations with the router. If not, proceed to the next step to see if the device is connecting to the network.

   2. List the devices connected to the local network using the Address Resolution Protocol (ARP) command line utility. This is a handy way to list the IP/MAC addresses of each device connected to your local network.

      At the command prompt, type:

      C:\>arp –a

      Press Enter.

      Take a look at the screenshot below. The command was run from the development server as indicated by Interface: 192.168.0.200. The first internet address, 192.168.0.1, belongs to the router, followed by IPs for the laptop, smartphone, and netbook—outlined in red. The MAC addresses represented by 00-00-00-00-00-00 are not real, but then you knew that. So far, so good, everything I think should be connected to the network is connected. If one of your reserved IPs is missing, at least you’ll know that’s the place to start troubleshooting.

      

      Just so you know, the IP/MAC pairs are cached. Devices no longer connected to the local network may still show up. Here’ how to flush the ARP cache:

      At the command prompt, type:

      C:\>arp -d -a

      Press Enter.

   3. Check the ZoneAlarm firewall configuration on development server. Confirm that the:

      • Firewall is not set to Stop All Internet Activity
      • Firewall Trusted Zone is set to Medium
      • Device IPs have been added to the ZoneAlarm Trusted Zone

      To quickly rule out the ZoneAlarm Firewall as the source of all your woes, disable ZoneAlarm’s Trusted Zone security by dragging the Trusted Zone security slider to Off. Since this completely disables the development server’s firewall on the local network side of things, I like to disconnect the local network from the Internet by unplugging the phone line, coax cable, or optical cable (lucky you) from the modem. If this solves the problem, set the Trusted Zone security level back to Medium and review Step 4 above.

      If other devices are using ZoneAlarm, check their configuration as well.

   4. Check the DHCP address reservations, confirm that:

      • The router’s DHCP Server is enabled
      • The networked devices have been assigned IP address and that they are within the router’s DHCP address range
      • The MAC address is correct for each device
   5. If you are using MAC filtering, check your router to confirm that:
      • Each device’s MAC address has been correctly entered

      • Filtering has been set to Turn MAC Filtering ON and ALLOW computers listed to access the network

        To quickly rule out MAC address filtering as the bane of modern networking, temporarily disable it by selecting Turn MAC filtering Off from the from the drop down list under the MAC Filtering Rules section of your router.

        Review Limit network access with MAC filtering

   6. When in doubt, reboot devices and router. Does this actually help? Well, sometimes…

No comments yet…