9.3. Examples of Network Problems and Solutions

This section describes troubleshooting guidelines and shows several examples of networking problems and approaches you can take to resolve them. The solutions tell how the failing component is isolated and how the problem was ultimately resolved. These examples give you some ideas in resolving network-related problems; they do not describe a step-by-step method of resolving problems.

For examples involving the CNS, see Cray Network Subsystem (CNS) Software Release Overview and Installation Guide.

For examples involving the CPES, see Cray Programming Environment Server (CPES) Release Overview and Installation Guide.

9.3.1. Troubleshooting Guidelines

Use the following guidelines to help you troubleshoot reported problems:

The following are common problems that you might encounter:

9.3.2. Troubleshooting Exmples

This section describes the most common problems encountered on the network and provides suggestions for solving them.

9.3.2.1. Connection Problems

The following problems can occur when a user is trying to connect to a remote host. In this section, the message is given (message text is shown in bold monospace font), followed by a description of the problem, the probable cause, and a possible solution. Some of the problems have more than one probable cause and possible solution listed.

Problem 1: Connection closed by remote host

A user has established a connection to a remote host, and the connection closes before the user logs out.

Cause:

This usually occurs because the remote host performed a shutdown and severed the connection, or the user process for the associated daemon was terminated.

Solution:

Use the ping(8) command to determine whether the host is running. Determine whether the remote host is down by contacting the host network administrator. If the host is not down, use telnet(1) to reestablish the connection.

Problem 2: Connection refused

Users cannot connect to a remote host. The remote host is up, and the interface is up, but a connection cannot be established. Several possible causes and solutions for the problem follow.

Possible Cause A:

The wrong port number for the program is listed in the /etc/services file on the local or the remote host.

Solution:

Check the protocol's port number in the network services file (/etc/services) on the local host. It must agree with the port number shown in the default network services file. If these numbers match, ask the network administrator on the remote host to perform the same check. Assume that the result of the check is as follows:

Network services, Internet style
#
telnet   25/tcp

The telnet daemon should have port number 23 instead of 25; therefore, the /etc/services file that is in error must be edited accordingly. The /etc/services data file should always keep the standard protocol port numbers. When the client program is started (that is, a user initiates a command), it opens /etc/services, obtains a port number, and looks for a daemon program that is listening on that remote host port.

When the daemon program is started (at boot time or when the network administrator starts it separately), the daemon opens /etc/services, obtains a port number, and listens for a request on that port. Therefore, if someone changes the port number in /etc/services on the client, the client will request a port number other than the one on which the standard daemon program is listening. If the daemon program is listening on a nonstandard port number, it does not recognize a client's request on a standard port number. A connection cannot be established unless both port numbers agree.

If it is necessary to use a nonstandard port number (this is often done for testing), use the following procedure to start a daemon or client program on a different port number without interfering with the standard network programs and daemons:

  1. To start a telnet server on port 35, add another line to the /etc/inetd.conf file as follows:

    35 stream tcp nowait root /etc/telnetd telnetd

    This line enables two telnet servers, one at port 23 (default) and the other at port 35. (You can test a trial version of telnet by enabling two telnet servers.)

  2. To connect to the telnet server on port 35, the client telnet(1) program from a remote host issues the following commands:

    # telnet
    telnet> open hostname 35

Now the two servers are talking because the port numbers agree. (If a server is not invoked by inetd (for example lpd or sendmail), these commands can be entered directly from the command line.)

In an implementer's own programs, the port number is sometimes embedded in the code. If this is the case, check the source code.

Possible Cause B:

The /etc/inetd daemon is down.

Solution:

If TCP/IP users cannot connect to any of the networking services on a particular host, contact the network administrator for the remote host to determine whether inetd is operating.

If remote users cannot connect to the local TCP/IP host, enter the ps(1) command with the -ae options to determine whether inetd is running. For example, the following ps -ae output indicates that inetd is not running, because inetd is not listed:

# ps -ae

81   ?   0:00    lpd
83   ?   0:00    sendmail

The following dialog activates inetd on the TCP/IP host and verifies that the daemon is now running:

# /etc/inetd

# ps -ae

81   ?   0:00    lpd
82   ?   0:00    sendmail
85   ?   0:00    inetd

Possible Cause C:

The server is not enabled by /etc/inetd.conf.

Solution:

If TCP/IP users can connect with other network services but cannot connect with a particular service on a host, contact the network administrator for the remote host to determine whether the daemons on the host are operating.

If remote users cannot connect to a particular service, but can connect to other services on the local TCP/IP host, your /etc/inetd.conf file is probably not set up correctly. Enter the netstat command with the -a option to determine whether the remote service is running.

The following output from netstat -a verifies that the telnetd service is not listening because telnet is not listed:

# netstat -a

Active connections (including servers)
Proto   Recv-Q   Send-Q   Local Address   Foreign Address    (state)
tcp       0 	      0      *.smtp          *.*                LISTEN
tcp       0        0      *.exec          *.*                LISTEN
tcp       0        0      *.shell         *.*                LISTEN
tcp       0        0      *.login         *.*                LISTEN
tcp       0        0      *.finger        *.*                LISTEN
tcp       0        0      *.ftp           *.*                LISTEN

If the telnetd service is not listening, view the /etc/inetd.conf file to determine whether the telnet service is enabled. If not, add the telnet entry to the /etc/inetd.conf file and issue a SIGHUP signal to the inetd process.

Use netstat -a again to verify that the daemon is now running:

# netstat -a

Active connections (including servers)
Proto   Recv-Q   Send-Q   Local Address   Foreign Address    (state)
tcp       0 	      0      *.smtp          *.*                LISTEN
tcp       0        0      *.exec          *.*                LISTEN
tcp       0        0      *.shell         *.*                LISTEN
tcp       0        0      *.login         *.*                LISTEN
tcp       0        0      *.finger        *.*                LISTEN
tcp       0        0      *.ftp           *.*                LISTEN
tcp       0        0      *.telnet        *.*                LISTEN

Problem 3: Connection timed out

The local host is trying to connect to the remote host but is not making an active connection. The telnet(1) program sent a packet to a specific address, but no hosts are responding. The telnet client program times out if a connection is not made within a certain time limit (usually between 30 and 75 seconds).

Example:

Assume that the user from the local TCP/IP host issued the following command:

# telnet hostname

telnet ....... connection timed out

Possible Cause A:

The remote host or network is down.

Solution:

If you suspect that the remote host or network is down, contact the network administrator for the host and request the host status.

Possible Cause B:

An incorrect Internet address is specified for the remote host.

Solution:

A conflict in the Internet address can arise from the following situations:

  • A user entered an incorrect Internet address on the command line. The user should retry the command, using the official host name or alias (to avoid reentering an incorrect Internet address).

  • A network administrator changed the Internet address of the remote host without informing the other hosts on the network. The address associated with the host is different from that in the local /etc/hosts table. The network administrator for the host should verify that the address is correct.

  • The local host table contains varying entries for the remote host. Only the first entry is used, regardless of which one is correct. Therefore, if multiple entries for a remote host appear in your /etc/hosts file, ensure that the first one is correct and delete the others.

Possible Cause C:

There is a hardware problem.

Solution:

Check the connections between the Cray system and the network hardware.

Possible Cause D:

The remote host's interface is down. (If the network hardware interface on the local TCP/IP host is down, the error message Network is unreachable appears.)

Solution:

If you suspect that the remote host's network interface is down, contact the network administrator and request the host's status.

Possible Cause E:

Nonexistent or incorrect routes are set up.

Solution:

If you suspect that the remote host's route tables are configured incorrectly, contact the network administrator and request the host's status. If the route entry on the local TCP/IP host is at fault, the error message Network is unreachable appears.

Problem 4: Login incorrect

A user is attempting to issue the rlogin(1) command and receives the error message Login incorrect.

Cause:

The error message is returned from the remote host because the user entered an invalid user name or password for the host. When an invalid user name is specified, or an autologin is impossible because /etc/hosts.equiv or $HOME/.rhosts is not set up to allow an autologin, the user receives a prompt for a login and password.

Solution:

  • Set up the /etc/hosts.equiv or $HOME/.rhosts file correctly so that the user is not prompted for a password.

  • Users must know their valid accounts and passwords on the remote hosts.

Problem 5: The .netrc file not correct mode

A user attempts to use ftp(1) with autologin to a remote host. The user's $HOME/.netrc file is set up properly with machine, username, and password entries, but the error message is returned, and ftp aborts.

Cause:

The file has read permissions set for someone other than the owner. Because of the sensitivity of information in $HOME/.netrc, the $HOME/.netrc file should be accessible only to the owner.

Example:

The following permissions are incorrect:

-rw-r--r--    1 peter other         24 Dec 14:14 /usr/peter/.netrc

Solution:

Change the access mode of the .netrc file to 600, as follows:

#  chmod 600 /u2/peter/.netrc

The following dialog verifies that the mode was changed:

# ls -la .netrc
-rw-------   1 peter other        24 Dec 26 14:14 /usr/peter/.netrc

Problem 6: Network is unreachable

The user attempts to connect to a host outside the local area network (LAN) and cannot establish the connection. Both hosts are known to be up.

Cause:

  • The local network hardware interface is down. If the remote interface is down, the error message Connection refused is returned.

  • The local network hardware interface is up, but the Internet address associated with it is incorrect. The interface is on a network that is different from the one for which it was intended.

  • The route was deleted for the local interface.

  • A route was not set up for the destination host.

  • An incorrect route was set up for the destination host.

Solution:

  1. If users cannot perform a telnet(1) operation back to themselves (using the local host name rather than loopback), the problem is in the interface.

    Example:

    User peter on crayhost issues the following command:

    # telnet crayhost
    Trying.....
    network is unreachable

    Enter the netstat command with the -i option to determine whether the local interface board is up, as follows:

    netstat -i
    
    Name    Mtu     Network     Address      Ipkts  Ierrs  Opkts  Oerrs  Collis 
    qfa0*   1500    twgnnet     crayhost     59803  0      45458  0      0 
    lo0     1536    Loopback    localhost    5601   0      5601   0      0 

    The asterisk following qfa0 indicates that the interface is down. Use the ifconfig(8) command to initialize the interface, as follows:

    ifconfig qfa0 crayhost up 

    The following output from netstat -i verifies that the interface is up:

    netstat -i
    
    Name    Mtu     Network     Address      Ipkts  Ierrs  Opkts  Oerrs  Collis 
    qfa0    1500    twgnnet     crayhost     59803  0      45458  0      0 
    lo0     1536    Loopback    localhost    5601   0      5601   0      0 

  2. If users can perform a telnet(1) operation to themselves, but not to anyone else on the local network, verify the address of the local interface.

    Example:

    User peter is on crayhost (local network 32) and is trying to perform a telnet operation to cray2, as follows:

    # telnet cray2
    Trying ... 
    network is unreachable

    Enter the netstat -in command:

    netstat -in
    
    Name    Mtu     Network     Address      Ipkts  Ierrs  Opkts  Oerrs  Collis 
    qfa0    1500    31          31.0.18.121  1373   0      753    0      0 
    lo0     4608    127         127.0.0.1    394    0      394    0      0 

    Although peter thought his network hardware interface was configured on network 32, it was actually configured on network 31. Therefore, peter must perform the following steps:

    1. Check the Internet address in the /etc/hosts table for the interface. The following dialog shows that crayhost was set to an incorrect address:

      # cat /etc/hosts
      
      31.0.18.121     crayhost
      32.0.0.2        cray2

    2. Change the Internet address in this host file, and reassign the new address to the interface, using the following ifconfig(8) command (first ensure that you change the Internet address in the /etc/hosts file). Verify by using netstat -in. The dialog follows:

      # ifconfig qfa0 down
      # ifconfig qfa0 crayhost up
      
      Name    Mtu     Network     Address      Ipkts  Ierrs  Opkts  Oerrs  Collis 
      qfa0    1500    32          31.0.18.121  1373   0      753    0      0 
      lo0     4608    127         127.0.0.1    394    0      394    0      0 

    3. If the host table appears to be correct, check the ifconfig parameters in /etc/config/ifconfig-x.options. This command should use the official host name instead of the Internet address.

      Acommon error occurs when users add their official host name to the loopback line (127.0.0.1). When they initialize the network, their interface board is assigned to 127.0.0.1 rather than to the intended Internet address in /etc/hosts.

    4. Try again to perform a telnet(1) operation to a host on the local network.

  3. If users can perform a telnet(1) operation to themselves and to anyone on the local network, but not to a host on another network, the route is the problem. For example, peter is on network 32 (local host crayhost) and wants to perform a telnet operation to cray3 on network 68.

    Enter netstat -rn to verify the following routes that are set up, as follows:

    # netstat -rn
    
    Routing tables
    Destination     Gateway         Flags    Refs     Use     Interface
    32              32.0.18.121     UG       4        1129    qfa0
    127             127.0.0.1       U        0        0       lo0

    This route table shows that peter can get to only networks 32 and 127 (loopback). peter must set up a route for network 68. For example, if host kit on his network were the gateway to network 68, peter would add the route as shown in the following example.

    # route add net 68 kit
    # netstat -rn
    
    Routing tables
    Destination     Gateway         Flags    Refs     Use     Interface
    68              32.0.0.4        UG       0        354     qfa0
    32              32.0.18.121     UG       4        1129    qfa0
    127             127.0.0.1       U        0        0       lo0

    Because kit is the gateway to network 68, it contains two addresses: one for network 68, and one for local network 32. Because crayhost is on network 32, the gateway host address that should be used is the same as that of crayhost (for example, 32.0.0.4).

    When multiple gateways are involved, another problem occurs with routes. Then you must determine which intermediate gateway is set up with improper routes.

    If the fault does not lie with the routing commands, use arp -a to examine /sbin/arp entries. Ensure that the remote host has a gateway configured for it, and that the correct hardware address for the gateway has been properly mapped to its host name. Make any necessary corrections and try again to perform a telnet(1) operation to the remote host.

Problem 7: Ruserok: permission denied

A user is trying to use the rsh(1), remsh(1), rcp(1), or rlogin(1) command and receives the error message.

Example:

User peter on crayhost attempts a remote shell (rsh or remsh) command on a given host through sue's account, and issues the following command:

$ rsh hostname -l sue who
ruserok: permission denied 

Several possible causes and solutions follow:

Possible Cause A:

The $HOME/.rhosts file on the remote host does not exist or is not set up to allow access to the user.

Example:

User sue's $HOME/.rhosts file is not set up to allow peter to use her account; the contents of her $HOME/.rhosts file are as follows:

crayhost sally george

In this example, sue has authorized access for sally and george, but not for peter.

Solution:

Create or update the $HOME/.rhosts file on the remote host to allow access.

Example:

User sue's $HOME/.rhosts file should be modified as follows:

crayhost sally george peter

Possible Cause B:

The $HOME/.rhosts file on the remote host is not owned by the user who owns $HOME.

Example:

User sue's $HOME/.rhosts file is owned by anne, as shown in the following ls(1) output:

$ ls -l .rhosts 
-rw-------   1 anne     users         22 Dec 16 15:09 .rhosts

Solution:

The super user must change the owner of the $HOME/.rhosts file to the owner of $HOME.

Example:

The super user uses the chown(1) utility to change the file's ownership, as follows:

# chown sue .rhosts
# ls -l .rhosts 
-rw-------    1 sue      users         22 Dec 16 15:09 .rhosts 

Possible Cause C:

The host name is not specified.

Example:

Host birch has two names corresponding to two IP addresses. The $HOME/.rhosts file should include both names to ensure a name that matches the address used is found.

Possible Cause D:

The $HOME/.rhosts file on the remote host is publicly writable.

Example:

Other users can modify user sue's $HOME/.rhosts file, as the following ls output shows:

# ls -l .rhosts 
-rw-rw-rw-    1 sue      users         22 Dec 16 15:09 .rhosts

Solution:

Change the permissions on the $HOME/.rhosts file to 600.

Example:

Use the chmod(1) utility to change the file's permissions, as follows:

$ chmod 600 .rhosts
 $ ls -l .rhosts
-rw-------    1 sue      users         22 Dec 16 15:09 .rhosts

Problem 8: Unknown host

A user tries to connect to another host and receives the error message. This error is generated from the client side.

Example:

# ftp otherhost
hostname: Unknown host. 
ftp> 

Cause:

There is an invalid entry in /etc/hosts. Each host to which the user wants to connect must have a valid entry in the local hosts file unless the user specifies the Internet address of the destination host. The remote host does not need an entry for the user in the hosts file, because the IP header contains the source address.

Solution:

Check the entry in /etc/hosts for the host name to which the user is trying to connect. Ensure that no comment indicator (#) precedes the entry.

9.3.2.2. sendmail Problems

This section discusses error messages that can occur when a user is trying to use the sendmail(8) facility. It offers guidelines for analyzing and resolving the error message problems.

Problem 1: Host Unknown

A user attempts to send email from the Cray system, and the email is returned as undeliverable. This problem started only recently. The following is an example of a message returned by the system:

>From root Thu May 24 07:45 GMT 1990
Return-Path: <MAILER-DAEMON>
Received: by myhost.domain.name
        id AA07406; 5.61/CRI-7.0; Thu, 24 May 90 02:45:18 -0500
Date: Thu, 24 May 02 02:45:18 -0500
From: Mail Delivery Subsystem <MAILER-DAEMON>
Full-Name: Mail Delivery Subsystem
Message-Id: <9005240745.AA07406@myhost.domain.name>
Subject: Returned mail: Host unknown
To: yourid

   ----- Transcript of session follows -----
550 yourid@yourhost... Host unknown

   ----- Unsent message follows -----
Received: by myhost.domain.name
        id AA07404; 5.61/CRI-7.0; Thu, 24 May 90 02:45:18 -0500
Date: Thu, 24 May 02 02:45:18 -0500
From: John Doe <yourid>
Full-Name: John Doe
Message-Id: <9005240745.AA07404@myhost.domain.name>
TO: yourid@yourhost

This is the message I wanted to send to you.

The Host unknown message indicates that sendmail could not find the name yourhost in the table of host names. This table provides the mapping of names to Internet addresses.

Using the preceding information, you can conclude that one of the following problems exists:

  • The sendmail program contains an error.

  • The sendmail.cf file is not configured properly.

  • The routine that performs the host mapping function (/etc/hosts or the name server, depending on which one your site is using) is not correct, which causes the output that is returned by gethostbyname(3) to be in error.

The reason for this conclusion is that these are the only components involved in determining valid host names. The part of the sendmail program that creates destination addresses is suspected because the destination address cannot be found. The process of resolving valid host names is suspected because the error message indicates that the host name is unknown.

To isolate the cause of this problem, look at the changes that are made to these components on the Cray system. For this example, assume that you have changed from using the /etc/hosts file to using the name server, and you have changed the sendmail configuration file.

  1. Check to determine whether the problem was introduced by the change from the /etc/hosts file to the name server. To test this possibility, you must go back to using /etc/hosts. Because the existence of the /etc/hosts.usenamed file indicates that the name server is being used, delete this file.

  2. Attempt to send a test message to yourid@yourhost. If the email is delivered to yourid@yourhost, the /etc/hosts file is not in error.

Using this information, you can conclude that the problem is either with the method that sendmail used to interface with the name server or with the name server itself. Change back to the name server, and look at the tools available to assist in debugging the name server. The program nslookup(1) is a tool that queries the name server and displays the results. Following is a sample nslookup(1) dialog:

prompt> nslookup

Default Server: myhost.domain.name
Address: 128.162.75.1

> yourhost
Server: myhost.domain.name
Address: 128.162.75.1

Name: yourhost.domain.name
Address: 128.162.154.12

> ^D
prompt>

The output from nslookup indicates that the name server does know about host yourhost. Therefore, the problem must be with the method that sendmail used to interface with the name server. To determine the host name that sendmail is using when communicating with the name server, execute the following:

prompt> /usr/lib/sendmail -bt
ADDRESS TEST MODE
Enter <ruleset> <address>
> 0 yourid@yourhost
rewrite: ruleset 3 input: "yourid" "@" "yourhost"
rewrite: ruleset 8 input: "yourid" "@" "yourhost"
rewrite: ruleset 8 returns: "yourid" "@" "yourhost"
rewrite: ruleset 3 returns: "yourid" "<" "@" "yourhost" ">"
rewrite: ruleset 0 input: "yourid" "<" "@" "yourhost" ">"
rewrite: ruleset 3 input: "yourid" "@" "yourhost"
rewrite: ruleset 8 input: "yourid" "@" "yourhost"
rewrite: ruleset 8 returns: "yourid" "@" "yourhost"
rewrite: ruleset 3 returns: "yourid" "<" "@" "yourhost" ">"
rewrite: ruleset 0 returns: "^V" "tcp" "^W" "yourhost" "^X" "yourid" "@" "yourhost"
> ^D
prompt>

The output shows that sendmail attempts to establish a TCP/IP connection with host yourhost (that is, the name following "^W"). This appears to be correct because yourhost is known to the name server. At this point, all you know is that sendmail is using the alias yourhost when it queries the name server, rather than using the official host name (yourhost.domain.name) that is displayed in the output from nslookup.

Next, look at the sendmail.cf file, and find the rule that produces the results returned by ruleset 0, as follows:

R$*<@$+>$*           $#tcp $@$2 $:$1@$2 

The results returned by ruleset 0 are indicated on the right side of this rule. For example, tcp indicates a TCP/IP connection, shown as "^V" "tcp" in the output; $2 represents the token that indicates the destination host's name, shown as "^W" "yourhost" in the output; and $1@$2 represents the token that indicates the recipient's email address, shown as "^X" "yourid" "@" "yourhost" in the output. The character strings $1 and $2 represent the tokens that are created by the left side of the rule.

To ensure that sendmail always uses the official host name, change the rule to the following:

R$*<@$+>$* $#tcp $@$2.$D $:$1@$2.$D

After making this change to the configuration file, you can send email addressed to yourid@yourhost, and it now works properly.

Problem 2: Cannot reply to e-mail originating from the Cray

A user attempts to reply to email received from a user on the Cray system, and the reply is returned as undeliverable. Using this information, you can conclude that one of the following problems exists:

  • The sendmail program that exists on the Cray system contains an error.

  • The sendmail program is not configured properly on the Cray system.

  • The official host name for the Cray system is not being used.

  • The sendmail program on the remote system contains an error.

  • The sendmail program is not configured properly on the remote system.

  • The routine that performs the host mapping function (/etc/hosts or the name server, depending on which one your site is using) is not correct, which causes the output that is returned by gethostbyname(3) to be in error.

The problem must be either with the method the Cray system uses to build its return address or with the method the remote system uses to return the email. (However, communication might be denied because of UNICOS/mp security label policies.)

To isolate the cause of this problem, look at the changes that have been made in the components on the Cray system. For this example, assume that the only factor that has changed is that you now use the name server rather than the /etc/hosts file. Currently, you do not know what has changed on the remote system, but after you eliminate the possibility of an error in the Cray components, you can begin to look at the remote system.

Because the sendmail program is not changed, and this problem is new, you can assume that the sendmail program that exists on the Cray system is not in error. The next step is to determine which address this sendmail program is using as its return address. Either the official host name for the Cray system is not set up correctly, or the configuration file incorrectly constructs the name it is given.

The following example is a sendmail debugging tool that produces the sequence of events that sendmail executes when it delivers email to the remote system:

prompt> /usr/libexec/sendmail -d8.99 -v yourid@yourhost
To: yourid@yourhost 
From: u3441

The -d option produces debug messages; the -v option requests a verbose execution method.

Note: When using this method to execute sendmail, you must enter the To: and From: lines, and the message text you are sending.

In the preceding output, the Cray host (that is, myhost) is telling the remote system (that is, yourhost) that its host name is actually myhost.domain.name.domain.name. This cannot be correct, because the domain name should appear only once. To determine whether the problem is in the method used to configure sendmail (that is, in the sendmail.cf file), you must first determine the method sendmail uses to construct this return address.

Then you can either consult the sendmail documentation or contact an analyst who is familiar with sendmail. Either way, sendmail uses the $j macro to define the local host's name, and thus, its return address. So you must locate the line in the sendmail.cf file that defines how $j is to be constructed. Locate the following line in the sendmail.cf file:

Dj$w.$D 

The values that are returned from the $w and $D macros are concatenated with a period (.) between them. The $w macro is the official host name of the local host, and the $D macro is the local domain name.

To determine the name that is being returned as the official host name for the Cray system, you can execute nslookup. The following is a sample session:

prompt> nslookup
Default Server: myhost.domain.name
Address: 128.162.75.1

> myhost
Server: myhost.domain.name
Address: 128.162.75.1

Name: myhost.domain.name
Address: 128.162.75.1

> ^D
prompt>

The $w macro returns myhostname.domain.name, which causes the sendmail configuration file to add incorrectly the value of $D (that is, the domain name) to the official host name.

Therefore, to resolve this problem, change the construction of the local host name in the sendmail.cf file by changing the line Dj$w.$D to Dj$w.