Once I set the capture for IP packets, I started a new capture, dialed the ISP, logged RAS
activity for 3 minutes, and examined the results, hoping to end the search for the random RAS
chatter that started this adventure.
Screens 4a through 4d show the capture that finally worked in several sections. Notice I
color-coded the frames to make the display easier to read and patterns of repeat activity easier to
identify. To color-code or otherwise fine-tune the capture view, when the capture window is open,
select Display and then Font, Color, or Options. If you're new to reading network frames, you'll
find that the last columns of the display, Source and Destination, help you identify and understand
which system is sending and which is receiving each frame. To see a frame broken down into its
constituent parts, rather than the summary view shown in these examples, double-click the frame
you're interested in.
Screen 4a shows the Point-to-Point Protocol (PPP) negotiation between RAS and the ISP to
establish the Internet connection. (For a list of protocols you often see in captures, see the
sidebar, "Common Network Protocols Glossary,".) Link Control Protocol (LCP)
requests are sent to my server with no return acknowledgment because LCP is disabled for this RAS
connection. A PPP Password Authentication Protocol (PAP) request is sent and acknowledged. After the
connection is successfully established, both sides exchange a series of control frames (Internet
Control Message Protocol--ICMP, and IP Control Protocol--IPCP).
Screen 4b shows the results of a ping to slate.mines.edu, the Colorado School of Mines network.
In frames 32 and 33, my server (VAIL) sends two Domain Name System (DNS) requests (Std Qry), one to
the ISP name server 166.93.1.3 and one to a root server at 128.63.2.53. In frame 34, the ISP name
server returns the address of slate.mines.edu as 138.67.01.03 (Std Qry Resp). Next, we see four
echo/echo-reply pairs in frames 35 through 45 between the RAS address 166.93.17.126 and slate at
138.67.01.03. These frames correspond to the four echos you see from ping on the command line.
Screen 4c shows that I issued an FTP request from another system on my LAN (ASPEN) through the
server with the RAS connection (VAIL and RAS connection) to a UNIX system at 166.93.8.14. Frame 160
shows me logged on as anonymous, and frame 162 contains the response Guest login ok, send your
complete e-mail address. In frame 164, I enter the password, "password," which the
UNIX system denies in frame 165. This incorrect password stops the logon procedure, so I restart the
logon in frame 172. This time, I enter the password, "pass@word.word," in frame 176, and
because my response is in the proper format for an email address, I successfully establish the FTP
session. The UNIX system responds in frame 178 with Guest login ok, access restrictions apply,
and in frame 180, I issue the bye command, which closes the connection in frame 181. This capture is
a great example of why we need to use anonymous user names for FTP sessions and is also strong
encouragement for network administrators to implement password controls for capturing and viewing
Network Monitor files.
The Ghost in RAS
Remember, my original reason for using Network Monitor was to identify random network traffic
over my dial-up connection. Color-coding DNS queries red helped to instantly identify the source of
the traffic, shown in Screen 4d. As frames 416 through 433 show, DNS queries are issued every two
minutes for the name JSPNRMPTGSBSSDIR. In the full version of the capture, this name repeats through
frame 479. Every second or third frame, one or another of the 12 DNS servers queried responds that
the name does not exist. (You can't see this part of the frame because I shortened the columns to
fit the screen on the page.) This pattern repeated every couple of minutes as long as the server was
connected to the ISP. As soon as I disconnected, the queries disappeared, something I proved by
another capture with the Network Monitor. Thus, I concluded that RAS, or the dial-up networking
module, is responsible for these DNS queries.
Now, because I set up my own DNS server I know that absolutely no references to
this name appear anywhere on my LAN. Furthermore, queries to 12 different InterNIC root name servers
all return with the name does not exist message. I searched the Microsoft Knowledge Base for
the string JSPNRMPTGSBSSDIR and found a match. My exact problem is described in article Q150820
(July 2, 1996), which, for some mysterious reason, has been removed from the Knowledge Base. The
article states, "The name JSPNRMPTGSBSSDIR is announced regularly and is a normal occurrence
from a Windows NT server or workstation running the Windows NT Remote Access Service."
Apparently, there is no way to disable this query and no description of its purpose. Now we all know
about the ghost in RAS, and the ghost's name is JSPNRMPTGSBSSDIR. More important, we have
demystified the network-monitoring process.
Register
