There is no doubt in my mind that Linux is the best operating system available, and having the source at your fingertips provides enormous leverage. That was reinforced for me after giving an X.25 course recently in Canberra, Australia. I had been unhappy with the ancient X.25 Packet Assembler/Disassemblers (PADs) the class used and thought that we ought to be able to use Linux to demonstrate many of the concepts in the course.
While Linux has good X.25 support, when using X.25 between pairs of Linux systems you have to modify the LAPB driver (to function as a Distributed Computing Environment). I felt that made class setup more difficult. On the flight home, I fired up my laptop and modified the LAPB driver to automatically set the appropriate parameter when loading the module with insmod or modprobe. Try doing that with a proprietary operating system!
When I got home, I had everything working, which means that future courses will be able to use Linux with Ethereal to give students hands-on exposure to X.25 using modern tools that they are likely to have available in the office and at home.
Speaking of Ethereal brings me to the topic of this month: Network debugging in a mixed Windows and Linux environment.
Many of us have to deal with Windows, sometimes on a daily basis. When we do, we often have to debug networking problems. It is very helpful to be able to find problems both from Linux and from Windows. This article explores the tools available to us in resolving network problems and observes that the strong similarity in those tools under Windows and Linux means that we can be more effective in both environments.
We will look at the mainstays like ping, traceroute (or tracert), nslookup, and so on. We will also look at Ethereal, as it is available for both Linux and Windows.
Tools common to Linux and DOS
Probably you are all familiar with tools under Linux like ping, traceroute, ifconfig, and so forth. However, the over emphasis on the GUI under Windows leads many people to believe that similar tools are not available for Windows. That is just not true; all you need to do is to fire up a command prompt. Click on Start, Run, enter command under Win9x, or cmd under Windows NT, and then click on Ok. Those same tools are also available as MS-DOS Prompt under Start, Programs. Once you have started a command prompt, a number of tools become available that behave in similar ways to tools under Linux.
First and foremost, there is ping. This command operates a little differently than the Linux ping command. Here is an example:
Pinging 10.0.0.6 with 32 bytes of data:
Reply from 10.0.0.6: bytes=32 time=17ms TTL=255Reply from 10.0.0.6: bytes=32 time=8ms TTL=255Reply from 10.0.0.6: bytes=32 time=10ms TTL=255Reply from 10.0.0.6: bytes=32 time=5ms TTL=255C:\>As you can see, the Windows version of ping only sends four ICPM echo requests, and does not list quite the same information that Linux does. It also accepts some different flags than the Linux version does. To find out more about the flags it accepts, simply enter ping by itself in a command window.
Another useful tool under Windows is tracert, better known as traceroute under Linux. The Windows tracert functions in a similar way to traceroute under Linux, except it sends ICMP echo requests rather than sending UDP messages to high port numbers as traceroute does. To find out all the flags that tacert accepts simply enter tracert by itself in a command window.
Often when you first debug networking problems under Windows, you want to know exactly how the system's various interfaces are configured. While you can rummage around in configuration windows to find that information, there are commands available under Windows that provide similar information to the Linux ifconfig command. However, different commands must be used under Windows 9x and Windows NT.
Under Windows 9x, using the command winipcfg/all will bring up a dialog box similar to that shown in Figure 1. The dialog box brings together all the configuration information in one place and allows you to check each interface.
Under Windows NT, you can obtain the same information with the ipconfig/all command as shown below:
Windows NT IP Configuration
Host Name . . . . . . . . . : vmwarent4.ns.aus.com DNS Servers . . . . . . . . : 10.0.0.2 Node Type . . . . . . . . . : Hybrid NetBIOS Scope ID. . . . . . :
IP Routing Enabled. . . . . : No
WINS Proxy Enabled. . . . . : No
NetBIOS Resolution Uses DNS : No
Ethernet adapter AMDPCN1:
Description . . . . . . . . : AMD PCNET Family Ethernet Adapter Physical Address. . . . . . : 00-50-56-9E-00-06 DHCP Enabled. . . . . . . . : Yes IP Address. . . . . . . . . : 10.0.0.162 Subnet Mask . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . : 10.0.0.2 DHCP Server . . . . . . . . : 10.0.0.6 Primary WINS Server . . . . : 10.0.0.2 Lease Obtained. . . . . . . : Saturday, December 16, 2000 11:34:35 PM Lease Expires . . . . . . . : Sunday, December 17, 2000 11:34:35 AMC:\>If you use dynamic host configuration protocol (DHCP) on your Windows systems, you can use those commands to release and renew IP addresses. Simply enter ipconfig/release or winipcfg/release to release IP addresses, and ipconfig/renew or winipcfg/renew to renew IP addresses.
Just as useful is the netstat command under Windows. It provides output similar to that of the same command under Linux, but as always with Windows, does things differently. That is shown below.
Proto Local Address Foreign Address State TCP 10.0.0.150:1025 10.0.0.6:139 ESTABLISHED TCP 172.30.0.161:2307 172.30.0.254:3128 CLOSE_WAIT TCP 172.30.0.161:2310 172.30.0.254:3128 CLOSE_WAIT TCP 172.30.0.161:2313 220.127.116.11:110 TIME_WAIT TCP 172.30.0.161:2314 18.104.22.168:110 TIME_WAIT TCP 172.30.0.161:2249 172.30.0.254:23 ESTABLISHED TCP 172.30.0.161:2287 172.30.0.254:23 ESTABLISHED UDP 10.0.0.150:137 *:* UDP 10.0.0.150:138 *:* UDP 127.0.0.1:1286 *:* UDP 172.30.0.161:137 *:* UDP 172.30.0.161:138 *:*C:\>Try netstat -h for more information on the command line flags that it accepts.
The Windows nbtstat command displays the NetBIOS names registered on a remote system. For example:
C:\WINDOWS\DESKTOP>nbtstat -a samba
NetBIOS Remote Machine Name Table
Name Type Status
---------------------------------------------SAMBA <00> UNIQUE RegisteredSAMBA <03> UNIQUE RegisteredSAMBA <20> UNIQUE Registered..__MSBROWSE__.<01> GROUP RegisteredSAMBANET <00> GROUP RegisteredSAMBANET <1D> UNIQUE RegisteredSAMBANET <1E> GROUP RegisteredMAC Address = 00-00-00-00-00-00The Samba nmblookup command can provide similar information, as shown below:
[root@nemesis root] nmblookup -S samba
querying samba on 10.0.0.255
Looking up status of 10.0.0.2
received 7 names
SAMBA <00> - M
SAMBA <03> - M
SAMBA <20> - M
..__MSBROWSE__. <01> - M
SAMBANET <00> - M
SAMBANET <1d> - M
SAMBANET <1e> - M
Other available tools include nslookup (only under Windows NT and Windows 2000) and nbtstat (whoes Linux counterpart is nmblookup, a tool from Samba).
Ethereal to the rescue
I reckon that the most useful network-debugging tool available is Ethereal, but then I am biased as a part of the Ethereal team. Ethereal is a packet capture and analysis tool that can display the smallest detail of a large and ever increasing number of protocols. The current version of Ethereal is 0.8.15. Figure 2 shows Ethereal displaying Label Distribution Protocol packets.
Due to the efforts of various teams around the world that have ported GTK+ and libpcap to Windows, you can now run Ethereal under Windows as well. SMB, the protocol underlying Microsoft Windows Networking, is now among the growing number of protocols that Ethereal understands. So it is even possible to diagnose many Windows Networking problems with Ethereal. Please see the Resources section for more details on Ethereal.
Watch out though! Just recently the Ethereal team discovered a problem (caused by a chain of problems) with the SMB decode for the Windows version of Ethereal. Windows NT does not return the correct date information when responding to a Get File Attributes SMB command. That causes the Windows gmtime routine to return NULL rather than a pointer to a string. Ethereal would blindly index into the string and crash. Under Unix Ethereal happily reported file times well before 1970! Oh well, the bug is fixed now, or it will be when the next version of Ethereal is released. That is yet another demonstration of the power of open source software. Because the source is available, anyone can fix the problems.
There are a number of available tools for network troubleshooting under Windows and Linux, many with common names and functions, though with slight differences between them.
It appears we will see more and more open source tools under both Linux and Windows, which is a welcome development.
By the way, there is still some work to do under Ethereal before it will properly display X.25 over Ethernet. The developers who coded the driver for X.25 over Ethernet chose to include an unused frame type allocated to Digital Equipment. Since it will only take about half an hour get Ethereal to treat that frame type as X.25 over Ethernet, I might as well get started now!