|
HAVE I HELPED?
|
A PEEPING TOM MANUAL FOR YOUR NETWORK
For basic troubleshooting on your home network and PC, you should see this page. Here we will discuss more detailed troubleshooting.
There are many levels of debugging. For fundamental ethernet, TCP/IP [that is the protocol that your PCs talk to the Internet with], and the application protocols, such as HTTP, FTP, etc. there is no better tool than to install a network "sniffer" and run the packet capture to see what is actually going on. The best sniffer may actually be a free one, ethereal. To install this on a Windows machine, you actually need to install two pieces of software, WinPcap and Ethereal, so read the instructions carefully.
For home networks, I actually recommend hubs instead of switches. "Hubs" have the advantage of replicating all the ethernet traffic from all the PCs on the local network onto each port, making it easy for a sniffer to see what is going on, no matter which port on the hub your sniffer is connected to. If you use a "switch" in your home network, you will NOT see all the traffic from all the PCs while you are plugged into any of the ports, unless you get a switch that has the capability of replicating [mirroring] all the traffic onto one of the ports. This is a capability you will probably only find on the more expensive switches, like the Cisco products and similar.
Most hubs will be restricted to 10 Mb/s, as opposed to the 100Mb/s capabilities of most switches, but I have found no problems at all running a 10 Mb/s LAN instead of a 100 Mb/s LAN for a home network. As time goes on, it will be more and more difficult to find hubs instead of switches, so this will be important to take into account. You will need to consider exactly where to position your sniffer in these situations. If it is desired to sniff "outgoing" traffic from a PC to a device not on the same subnet (although on the same switch), for example the Internet, then it is possible to see the bi directional traffic by being on a hub on either side of the switch.
If you have wireless or home PNA networks in addition to your ethernet network, all the traffic will not show up on either the wireless or the wired portion, since the wireless portion is actually "bridged" back to your other network. This means that the wireless port on the wireless bridge will not just simply replicate ethernet packets to the other ports if the ethernet is only meant for another station on the wireless side. If you only have one wireless device, then that's OK - all the packets will show up on the ethernet side, because it has nothing to talk to on the wireless side. If the wireless PCs don't talk to each other, but mostly to the Internet, then you are probably mostly OK. It is only the wireless-to-wireless communications that you will not be able to sniff from a non-wireless PC, or the wired-to-wired communications that you will not be able to see from the wireless side [just in case you have your sniffer on a wireless PC].
For WinNT4/Win2K/WinXP the events viewer can often be revealing. This can be found under start -> Administrative tools. For RedHat Linux, you should do a "tail -f /var/log/messages" in a terminal window and you will see most of the interesting events that occur on your machine.
If you run the server version of WinNT4/XP/Win2K/WinServer2003, it comes with its own sniffer. I am not familiar with its use, as I can't afford to fork over those large sums of money for the server product, but I am sure it is similar to ethereal. However, I am willing to bet that ethereal is superior, since it is open source software, and there are many people which work on ethereal and keep up the decodes. It just doesn't have all the fancy graphics that a sniffer like "Sniffer" has. [Looks like another case of "xerox" meaning "copy," .....sorry Sniffer.... :-( ].
Most of you are familiar with the task manager that comes with WinNT4/XP/Win2K, which actually lists all the running processes, as well as the overall applications. Zonealarm actually lists all the applications which are listening on TCP ports, which are the important processes to monitor, considering they are the ones which are liable to attacks from the Internet. If you press "CTL-ALT-DEL" on a Win98 machine you also get a task list, so there is even a small version of it here too. "Performance Monitor" on the WinNT4/XP/WIn2K is also available, but again, the server version of the software has more capabilities than the non-server version. Gotta spend those hundreds of dollars to get it.
Another great tool included with all machines is the "netstat" command line tool. On Windows machines, you can enter "netstat -s -p TCP" to get a list of TCP statistics, including "retransmissions," which are a sure indicator of trouble on your network somewhere. "Netstat -s -p UDP" does the same for UDP packets, and "netstat -s -e" reports them for the ethernet layer. "Netstat -an" displays the routing table used by the machine [same as "route print"]. "Netstat -a" lists the TCP and UDP ports the machine is listening on. Go here for some good info on "netstat."
Another trick you can use to help you troubleshoot your local PC and its communications is to use the TCPView tool, mentioned here. This will show you all the TCP communications in and out of your PC. It will also show all the UDP if you enable the entire view.