Showing posts with label TCP/IP. Show all posts
Showing posts with label TCP/IP. Show all posts

Windows Vista and Explicit Congestion Notification

With one of the most popular use for computers being Internet access, changes in Windows Vista, to support improved TCP networking, are significant. I've written about Scalable Networking, which contains 3 identified options - Receive-Side Scaling, TCP AutoTuning, and TCP Offload. Scalable Networking contains changes that are implemented from the client, and only require support from the client equipment.

There are more changes to the Vista TCP stack, though, and some of them require support from equipment outside the client network. Explicit Congestion Notification (ECN) is an option that reduces network problems caused by dropped packets, by letting the routers in the network (which drop packets, when overloaded) warn the client and server that they are approaching overload ("congestion").

Rather than experience packet drop (and require packet retransmission), the client and server can be warned before packet drop is necessary, and voluntarily reduce network use. If the endpoints (client and server) reduce network use, the routers in the network path between the endpoints become less overloaded, and are less likely to drop packets. This reduces network problems, and benefits all members of the network, including other endpoints and routers in other connections. By reducing packet retransmission, ECN can reduce Internet congestion in general.

Used inappropriately, however, ECN can actually increase Internet congestion. All Internet equipment is not ECN friendly, and WikiPedia mentions how enabling ECN might actually cause a problem, rather than preventing one.

Some outdated or buggy network equipment drops packets with the ECN bit set, rather than ignoring the bit[1].


ECN isn't granular - either you enable it, or you don't - and it potentially affects access to all web sites that you wish to visit. It may be more useful in specialised computers, that are intentionally used for high speed communication with specific web sites. It doesn't appear too useful for web surfing in general, right now.

For this reason, Vista is installed with ECN Disabled. If you try ECN Enabled, and you lose access to one web site, you'll have no choice but to Disable ECN, or face loss of access to the web site in question. As network hardware is upgraded, and becomes ECN friendly, enabling ECN will become a more practical option.

If you wish to use ECN, enter in a Vista command window (Run as Admin)
netsh interface tcp set global ecncapability=enabled
If you detect problems, such as lack of access to various web sites, enter similarly
netsh interface tcp set global ecncapability=disabled


>> Top

Windows Vista and Scalable Networking

Over a year ago, I explored an issue of Windows Vista and its problems with using default networking settings relevant to Windows Scaling. The first known problem with Windows Scaling was an exciting networking option called Receive Window AutoTuning, which became a problem when an older router was in use.

Besides AutoTuning, which is a problem with older routers, there are two additional networking options - TCP Offload ("Chimney") and Receive-side Scaling ("RSS"), which are a similar problem with older networking adapters. If your computer suffers from symptoms similar to the well known MTU setting problem, and you get no relief from disabling RWin AutoTuning, consider disabling TCP Offload and Receive-side Scaling.

In a Vista command window (Run as Admin), enter

netsh interface tcp set global chimney=disabled
netsh interface tcp set global rss=disabled


TCP Chimney Offload takes a portion of the TCP/IP network stack, currently run on your computer as part of the Windows operating system, and runs it in a dedicated processor on a TOE capable network adapter. Less work for the operating system + processing as part of the physical networking adapter = better performance.

Receive-side Scaling allows processing of incoming network traffic to be properly run on a multi-processor computer, by ensuring that all packets from a single TCP network connection are consistently processed by the same processor. All incoming packets for each TCP connection processed by the same processor = packets never getting out of sequence, which can be a problem otherwise with multiple processors. Obviously, you'll need a multiple processor system, to get any benefit here.

Try Internet access with TCP Offload and Receive-side Scaling disabled, and see if network performance improves. If it does, see if you can upgrade or replace your network card with one that is TOE capable, which was stated to cost $25 - $50 earlier this year. Once you have the right network hardware, or if the above change doesn't provide any relief from your symptoms, you can re enable TCP Offload and Receive-side Scaling
netsh interface tcp set global chimney=enable
netsh interface tcp set global rss=enable


If you do see a bandwidth improvement and / or network utilisation drop after enabling chimney and / or rss, restart the system. You may see still more improvement after restarting. Use of proper tools for objective measurement of bandwidth and network utilisation, access to high speed Internet service, and use of high bandwidth network applications like streaming video, will make the success of this change a bit easier to assess.

Besides Scalable Networking, look at other possible problems with Windows Vista Networking Innovations, in Windows Vista and Explicit Congestion Notification.

For more details about this issue, see

Setting The MTU In Windows Vista

Long ago, when I first heard of the dynamic tuning in the Windows Vista TCP/IP stack, I envisioned the manual setting of the static MTU to be a thing of the past. Unfortunately, I was wrong - the MTU is still a fixed setting, in Vista.

The legendary tool, DrTCP, which is used by everybody to change the MTU in Windows 2000 and XP, doesn't work under Windows Vista. Fortunately, Microsoft now allows us to adjust the MTU using the "netsh" command. As other commands in Windows Vista, you run "netsh" using the command window, in Administrative mode.

To see what interfaces you have on your computer, type

netsh interface ipv4 show subinterfaces

To change the MTU, type
netsh interface ipv4 set subinterface "Local Area Connection" mtu=nnnn store=persistent

where
Local Area Connection is the name of the network connection on your computer, from the list obtained above.
nnnn is the desired value for MTU.

Reboot after making the change.

>> Top

AutoTuning In Vista Maybe Not Ready For Prime Time

As you surf the web, you will be in conversation with dozens of web servers, and each conversation might have different latency and stability issues. On a less stable (or low bandwidth) connection, a small Receive Window would be a good idea; on a more stable (or high bandwidth) connection, a larger window gives much better performance. With Windows XP and previous, you were limited to a single Receive Window setting, which would apply to all Internet connections, all of the time.

One of the long awaited features in Windows Vista was the ability for it to dynamically determine the Receive Window size, by individual connection. Receive Window Auto-Tuning is one of the many significant improvements in Windows Vista, in my opinion.

For a few owners of computers running Windows Vista, connectivity to the local network, or the Internet, may be problematic. Symptoms are very like the well known MTU Setting problem - some servers, some of the time, can't be contacted, or give poor performance. Copying files locally, from one computer to another, may be fast in one direction, and agonizingly slow in another.

But we know that your local network isn't running through a router, so how would an MTU setting affect your local connection?

The MTU isn't always the culprit in this case. If you have an older firewall or router, that doesn't support Windows Scaling (an essential component in Receive Window Auto-Tuning), you may have this problem. Apparently the lack of Windows Scaling can affect local performance too.

If you are faced by symptoms like an MTU setting problem, that involve a computer running Windows Vista, first try disabling Auto-Tuning. In a Vista command window (Run as Admin), enter

netsh interface tcp set global autotuning=disabled
or
netsh interface tcp set global autotuninglevel=disabled

Then shutdown and restart.

Try Internet access with Auto-Tuning shut off, and see if things stabilise. If they do, see if you can upgrade or replace your router. Check with the vendor, and see if a firmware update is available; if not, consider replacing the router. If your router is incapable of supporting Windows Scaling, it may lack other features that you will also enjoy.

Besides RWin AutoTuning, look at other possible problems with Windows Scaling, in Windows Vista and Scalable Networking.

If you see no improvement in your symptoms, turn Auto-Tuning back on before making other changes. Layered Troubleshooting principles suggest one change at a time.
netsh interface tcp set global autotuning=normal
or
netsh interface tcp set global autotuninglevel=normal


Note the lexicographical variations expressed, above. Some experts state that the relevant keyword is "autotuning", others state "autotuninglevel". There is also a confusion about the value for "autotuning" / "autotuninglevel", which may be either "enabled" or "normal". I suspect that there are two possibilities, "autotuning=enabled" and "autotuninglevel=normal", but I haven't found an authoritative reference, discussing the possibilities.

For more information, see

>> Top

Advanced Windows Networking Using Internet Protocol

Windows Networking is the subsystem that lets you share files and printers, between computers running the various versions of Windows. Server Message Blocks, also called SMBs, are the foundation of Windows Networking. SMBs provide several crucial functions.



(Note): If you're not familiar with the concept of network layers, take a few moments and read about the OSI Network Model.

SMBs are not transported directly over the various physical networking components, as Layer 1 or 2 traffic. SMBs may be transported over Internet Protocol (IP), as well as alternate protocols like IPX/SPX or NetBEUI.

Windows Networking has historically used NetBIOS Over TCP/IP (NetBT) as an intermediate transport for SMBs over IP. Windows 2000, XP, and Vista however, will transport SMBs over IP, without NetBT, using directly hosted SMBs.

To remain compatible with the older versions of Windows, a Windows Networking client, running Windows 2000, Windows XP, or Windows Vista, can use either directly hosted SMBs, or it can use NetBT. If any server supports directly hosted SMBs, the client computer in question will bypass NetBT, when communicating with that specific server.

This dual compatibility, which allows Windows 2000 / XP / Vista clients to communicate with computers running other editions of Windows, is not without cost. Trying for two communications channels, when establishing a connection with any server, increases program complexity and network traffic. In some cases, it may increase latency.

We need to resolve one major misconception. It may appear that when you Disable NetBT, you are disabling Windows Networking over IP. This is not correct. When you Disable NetBT, you are merely disabling hosting of SMBs over NetBT. You then end up with SMBs hosted directly over IP. But look at address resolution on your LAN, before trying this. Don't make this change blindly.

If your LAN
  • Has a domain.
  • Has computers running only Windows 2000, Windows 2002 (aka Windows XP), Windows 2003 (aka Server 2003), Windows 2006 (aka Vista), and Windows 2009 (aka Windows 7).
  • Uses DNS, properly setup, for name resolution.
then you may wish to Disable NetBT, and (KB204279): use directly hosted SMBs. If any of the above are not true, you should Enable NetBIOS Over TCP/IP. Be consistent on all computers.

In the TCP/IP Properties - Advanced wizard, WINS, select Disable NetBIOS Over TCP/IP. Alternately, if you have the Default NetBIOS setting selected (instead of "Disable" or "Enable") on your client computers, and you have a DHCP server (not a NAT router with DHCP), you can disable NetBT from a DHCP server setting.

If you use directly hosted SMBs, whether alternately or exclusively, be aware of the security implications.
  • NetBT uses TCP and UDP ports 137 - 139.
  • Direct hosted SMBs use TCP port 445.

Be sure that all personal firewalls have the proper ports opened.

Here are the relevant ports used by SMBs over NetBT, per IANA port number allocation:

netbios-ns 137/tcp NETBIOS Name Service
netbios-ns 137/udp NETBIOS Name Service
netbios-dgm 138/tcp NETBIOS Datagram Service
netbios-dgm 138/udp NETBIOS Datagram Service
netbios-ssn 139/tcp NETBIOS Session Service
netbios-ssn 139/udp NETBIOS Session Service

And the relevant ports used by directly hosted SMBs:

microsoft-ds 445/tcp Microsoft-DS
microsoft-ds 445/udp Microsoft-DS


Similar to the effect of a personal firewall, SMBs can be setup to use secure channel communication, by using SMB Authentication and Encryption. If you ever see
The account is not authorized to log in from this station.

then check SMB Encryption and Signing settings.

And, if you have an integrated security suite (previously sold as anti-virus protection), you may have an anti-worm component protecting you. Anti-worm protection, if not correctly configured, may interfere with any or all of the above NetBT traffic. Different brands of products will cause different problems.

For more information:

>> Top

NetBIOS Over TCP/IP

Microsoft Windows, in its default state, uses TCP/IP, and NetBIOS Over TCP/IP, for networking. Sometimes, we forget this detail. NetBT is so easily overlooked, yet it is essential.

If we are looking at the output from "ipconfig /all", and we see


IP Address. . . . . . . . . . . . : 192.168.1.50
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.11
192.168.1.33
NetBIOS over Tcpip. . . . . . . . : Disabled
Lease Obtained. . . . . . . . . . : Wednesday, April 16, 2003 11:19:12
Lease Expires . . . . . . . . . . : Wednesday, April 23, 2003 11:19:12


Obviously, we're going to correct that. But what if we simply see

IP Address. . . . . . . . . . . . : 192.168.1.50
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.11
192.168.1.33
Lease Obtained. . . . . . . . . . : Wednesday, April 16, 2003 11:19:12
Lease Expires . . . . . . . . . . : Wednesday, April 23, 2003 11:19:12

Do we see any problem there? Probably not. Look in the TCP/IP - Advanced Properties wizard, WINS tab. There are 3 possible settings for NetBIOS Over TCP/IP
  • Default.
  • Enable.
  • Disable.

The last setting, Disable, becomes apparent when we see the first example above. But what if if we see the second example above? Well, that display can result from either the "Default", or the "Enable" setting. If it's not showing Disabled, it could be either.

The Default setting, according to the wizard, is for

Use NetBIOS setting from the DHCP server.

If your LAN
  • Has a domain.
  • Has computers running only Windows 2000, Windows 2002 (aka Windows XP), and Windows 2003 (aka Server 2003).
  • Uses DNS, properly setup, for name resolution.
then you may wish to disable NetBT, and use directly hosted SMBs.

But what if your LAN has a NAT router providing DHCP services, and / or has no domain? NAT routers are Operating System independent, and NetBT is a Microsoft Windows Networking feature. NAT routers have no setting for NetBIOS Over TCP/IP. If you select "Default", and you have a NAT router, what network functionality do you get?

The challenge is that this one setting affects multiple functions between your computer, and other computers, in both directions.
  1. Browsing: Ability to see other computers.
  2. File sharing: Ability to access resources on other computers.
  3. Name resolution: Ability to find out the addresses of other computers.


Depending upon what network hardware and software you have, any or all of the above functions may or may not work, in either direction (incoming or outgoing), between any pair of computers. And each different pair of computers may yield a different set of symptoms. If you have a NAT router providing DHCP services, the only way to deal with this reliably is to Enable NetBT consistently, on all computers.

In the TCP/IP - Advanced Properties - WINS wizard for all relevant network connections,

  • Select the radio button "Enable NetBIOS over TCP/IP".
  • Hit OK 3 times.
  • Close Network Connections, after enabling NetBT on all relevant network connections.

If you still see

NetBIOS over Tcpip. . . . . . . . : Disabled
after Enabling NetBT, check the TCP/IP NetBIOS Helper service.

Be safe - don't settle for "Default".

>> Top

Internet Connectivity Problems Caused By The MTU Setting

The messages sent and received between your computer, and the Internet web servers that you're accessing, may go thru dozens of networks. The Internet is, by design, dynamic. The networks that you use, to access any server, may change within seconds.

Any one of those networks might have a restriction on the maximum message (packet) size that it will accept. Each computer has a setting, called the Maximum Transmission Unit (MTU), which controls how large it may make any packet. The larger your packets, the fewer packets required for sending or receiving a web page, but the greater chance any network have a problem with your packet size.

Setting the MTU on your computer can be a double edged sword.


  • If you make the MTU too large, some networks will split (fragment) your packets. Some servers may have a problem with fragmented packets, causing the dreaded "Server not available..." error, or other symptoms.
  • If you make the MTU too small, your computer will send and receive small packets. You'll be able to access any server, thru any network, but a web page will require too many packets. The speed that your web pages download will make you think you're not connected at all.


If you have a problem accessing some websites (or running some programs like email or IM), but not others, or if this problem seems to come and go, you may have an MTU setting problem. The best known examples of this problem are those with dial-up or PPPoE sevice, or those using ICS. An MTU issue can affect anybody, though, and different people (computers) will, almost certainly, be affected differently, with different web sites being unreachable at different times.

Here are several articles, of differing technical detail and level, discussing the issue further, and offering ways to diagnose and correct it. Read through each one, until you find one that explains the issue to your liking. This list, like each of the ones that I create, is alphabetised.


When you get ready to adjust the MTU setting, make it easy on yourself. Download DrTCP, from DSLReports, and use it to make the changes for you. Simply copy the downloaded file into any convenient folder, and run it from there.

You'll be changing the "MaxMTU" or "MTU" value under Adapter Settings. If you have multiple network adapters, be sure to choose the one that provides the Internet service. For instructions about what values to change MTU to, see the articles linked above. Read all 6, and pick the one that you're most comfortable with.

Note: An MTU problem can be confused with, or masked by, a DNS problem, or LSP / Winsock Corruption. If you're here after trying the above procedures, unsuccessfully, consider each of the latter possibilities.

>> Top

Interpreting CDiag Output and Solving Windows Networking Problems

In any Client - Server relationship, if there is a problem, how do you identify if the problem is with the Client or the Server? What if there are actually two problems - how do you isolate each problem?

Every desktop support or network tech doubtless has his (her) own approach to this problem. But when you work face to face with a problem, it's easy to overlook the details, so how do you tell someone else how you solved a problem?

What if you can't work face to face with a problem? What if you have to ask questions, and have the symptoms described to you, by someone that you can't see? How about someone you can't even talk to (using realtime voice communication)? How do you gather enough diagnostic data to decide if a networking issue is related to connectivity, name resolution, or permissioning?

I start with CDiag. The CDiag log, from each computer on a LAN, can usually help isolate the source of a problem or problems that affect Windows File Sharing. My previous article What Is CDiag ("Comprehensive Diagnosis Tool")? explained how to setup a CDiag run, so the owner of a LAN can gather diagnostic data, and pass it to you (if you're providing assistance), or so you can setup and run CDiag (if you're using it in self-assist mode).

Now that you have two or more CDiag logs, how do you interpret them?

With one exception, the tests in CDiag are binary. Can Computer A ping Computer B successfully (by name / ip address)? Can Computer A view shares ("net view") of Computer B? By observing which test is successful, and which test is not, we can isolate the problem(s) between Computers A and B.

A successful ping by name, from Computer A to Computer B, verifies connectivity between Computers A and B, and verifies successful address resolution of Computer B. If the ping is unsuccessful, what error do you see? Does it show an inability to resolve the address of Computer B ("...could not find host..."), or does it show a connectivity problem ("Pinging nnn.nnn.nnn.nnn ... Request timed out")?

Similarly, successful viewing of network shares, as in Computer A able to get results from a "net view" of Computer B, verifies successful file sharing from Computer B to Computer A. In cases where Computer B can't be pinged from Computer A, but the results of "net view" of Computer B is successful, one can suspect a problem with TCP/IP (and look for gratuitous protocols like IPX/SPX).

There is also three-level pinging to observe. We can compare the results of pinging Computer B from Computer A, pinging Computer A from itself (by public ip address), and pinging Computer A from itself (by loopback ip address - 127.0.0.1). An inability to ping either Computer B, or Computer A, from Computer A, means we must first look for a problem on Computer A. Success or failure in pinging the loopback address identifies the network adapter or the IP stack, respectively, as the initial problem to be resolved.

If a third computer is involved, a single problem is somewhat easier to isolate. Where simple inability to ping Computer B from Computer A could point to a problem with either Computer A or B, inability for both Computers A and C to ping Computer B probably indicates a problem with Computer B.

Oh yes, the one non-binary test? When you ping Computer B by name, observe the resolved address. Is it equal to the ip address by which we ping Computer B (from "ipconfig /all")? A discrepancy here can indicate an address resolution problem, which will indeed lead to a variance of "access denied".

When all pinging between computers is successful, ruling out connectivity problems, one turns to analysis of the "net view" commands, and similar possibilities.

Let me try and describe what tests are included in a single run of CDiag.


  • Share Enumeration
  • Ad-Hoc Browser View
  • FullTarget Tests
  • PingTarget Tests

The FullTarget Test is run against a host which is expected to be running as a server (here you will need a consistent NetBIOS Over TCP/IP setting, on all computers). A FullTarget Test involves:

  • Ping the target.
  • Net view the target.

The PingTarget Test is run against a host which is running TCP/IP only. A PingTarget Test involves:

  • Ping the target.

In this example, I have 5 FullTargets (Pchuck1 by name and by IP address, PChuck2 by name and by IP address, and "127.0.0.1") ("127.0.0.1" automatically set as a target), and 3 PingTargets (Yahoo by name and by IP address, and the router).

set FullTarget1=PChuck1 192.168.1.50
set FullTarget2=PChuck2 192.168.1.51
set PingTargets=www.yahoo.com 66.94.230.32 192.168.1.1

This results in the following tests:

  • Net Share
  • Net View
  • Ping Pchuck1
  • Net View PChuck1
  • Ping 192.168.1.50
  • Net View 192.168.1.50
  • Ping Pchuck2
  • Net View PChuck2
  • Ping 192.168.1.51
  • Net View 192.168.1.51
  • Ping 127.0.0.1
  • Net View 127.0.0.1
  • Ping www.yahoo.com
  • Ping 66.94.230.32
  • Ping 192.168.1.1


Note that this is simply one set of tests, from a 2 computer LAN. Tests for a 3 computer LAN will be proportionally more complex.

In this example, starting from the CDiag Assembled Code, and run from PChuck1, we get this output log (showing no problems, with all tests returning positive results):

CDiagnosis V1.33

Start diagnosis for PChuck1

Enumerate Shares

Share name Resource Remark

-------------------------------------------------------------------------------
E$ E:\ Default share
IPC$ Remote IPC
D$ D:\ Default share
ADMIN$ C:\WINDOWS Remote Admin
C$ C:\ Default share
EDrive E:\
Shared Data E:\Data\Shared Data
The command completed successfully.

Adhoc Browser View

Server Name Remark

-------------------------------------------------------------------------------
\\PChuck1
\\PChuck2
The command completed successfully.


Full Targets PChuck1 192.168.1.50 PChuck2 192.168.1.51 127.0.0.1

Target PChuck1

"PChuck1 ping PChuck1"



Pinging PChuck1 [192.168.1.50] with 32 bytes of data:



Reply from 192.168.1.50: bytes=32 time<1ms TTL=128

Reply from 192.168.1.50: bytes=32 time<1ms TTL=128

Reply from 192.168.1.50: bytes=32 time<1ms TTL=128

Reply from 192.168.1.50: bytes=32 time<1ms TTL=128



Ping statistics for 192.168.1.50:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms


"PChuck1 net view PChuck1"

Shared resources at PChuck1



Share name Type Used as Comment

-------------------------------------------------------------------------------
EDrive E:\
Shared Data E:\Data\Shared Data
The command completed successfully.


Target 192.168.1.50

"PChuck1 ping 192.168.1.50"



Pinging 192.168.1.50 with 32 bytes of data:



Reply from 192.168.1.50: bytes=32 time<1ms TTL=128

Reply from 192.168.1.50: bytes=32 time<1ms TTL=128

Reply from 192.168.1.50: bytes=32 time<1ms TTL=128

Reply from 192.168.1.50: bytes=32 time<1ms TTL=128



Ping statistics for 192.168.1.50:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms


"PChuck1 net view 192.168.1.50"

Shared resources at 192.168.1.50



Share name Type Used as Comment

-------------------------------------------------------------------------------
EDrive E:\
Shared Data E:\Data\Shared Data
The command completed successfully.


Target PChuck2

"PChuck1 ping PChuck2"



Pinging PChuck2 [192.168.1.51] with 32 bytes of data:



Reply from 192.168.1.51: bytes=32 time<1ms TTL=128

Reply from 192.168.1.51: bytes=32 time<1ms TTL=128

Reply from 192.168.1.51: bytes=32 time<1ms TTL=128

Reply from 192.168.1.51: bytes=32 time<1ms TTL=128



Ping statistics for 192.168.1.51:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms


"PChuck1 net view PChuck2"

Shared resources at PChuck2



Share name Type Used as Comment

-------------------------------------------------------------------------------
CDrive Disk M:
Data Disk
DDrive Disk N:
Dnload 2004 Disk
EDrive Disk O:
HPDeskJet Print HP DeskJet 952C
Quarantine Disk
System Resources Disk
Utility Disk
The command completed successfully.


Target 192.168.1.51

"PChuck1 ping 192.168.1.51"



Pinging 192.168.1.51 with 32 bytes of data:



Reply from 192.168.1.51: bytes=32 time<1ms TTL=128

Reply from 192.168.1.51: bytes=32 time<1ms TTL=128

Reply from 192.168.1.51: bytes=32 time<1ms TTL=128

Reply from 192.168.1.51: bytes=32 time<1ms TTL=128



Ping statistics for 192.168.1.51:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms


"PChuck1 net view 192.168.1.51"

Shared resources at 192.168.1.51



Share name Type Used as Comment

-------------------------------------------------------------------------------
CDrive Disk
Data Disk
DDrive Disk
Dnload 2004 Disk
EDrive Disk
HPDeskJet Print HP DeskJet 952C
Quarantine Disk
System Resources Disk
Utility Disk
The command completed successfully.


Target 127.0.0.1

"PChuck1 ping 127.0.0.1"



Pinging 127.0.0.1 with 32 bytes of data:



Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

Reply from 127.0.0.1: bytes=32 time<1ms TTL=128



Ping statistics for 127.0.0.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms


"PChuck1 net view 127.0.0.1"

Shared resources at 127.0.0.1



Share name Type Used as Comment

-------------------------------------------------------------------------------
EDrive E:\
Shared Data E:\Data\Shared Data
The command completed successfully.


Ping Targets www.yahoo.com 66.94.230.32 192.168.1.1

Target www.yahoo.com

"PChuck1 ping www.yahoo.com"



Pinging www.yahoo.akadns.net [66.94.230.50] with 32 bytes of data:



Reply from 66.94.230.50: bytes=32 time=19ms TTL=57

Reply from 66.94.230.50: bytes=32 time=17ms TTL=57

Reply from 66.94.230.50: bytes=32 time=18ms TTL=57

Reply from 66.94.230.50: bytes=32 time=17ms TTL=57



Ping statistics for 66.94.230.50:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 17ms, Maximum = 19ms, Average = 17ms


Target 66.94.230.32

"PChuck1 ping 66.94.230.32"



Pinging 66.94.230.32 with 32 bytes of data:



Reply from 66.94.230.32: bytes=32 time=17ms TTL=57

Reply from 66.94.230.32: bytes=32 time=17ms TTL=57

Reply from 66.94.230.32: bytes=32 time=19ms TTL=57

Reply from 66.94.230.32: bytes=32 time=18ms TTL=57



Ping statistics for 66.94.230.32:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 17ms, Maximum = 19ms, Average = 17ms


Target 192.168.1.1

"PChuck1 ping 192.168.1.1"



Pinging 192.168.1.1 with 32 bytes of data:



Reply from 192.168.1.1: bytes=32 time<1ms TTL=150

Reply from 192.168.1.1: bytes=32 time<1ms TTL=150

Reply from 192.168.1.1: bytes=32 time<1ms TTL=150

Reply from 192.168.1.1: bytes=32 time<1ms TTL=150



Ping statistics for 192.168.1.1:

Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

Minimum = 0ms, Maximum = 0ms, Average = 0ms


End diagnosis for PChuck1

Since your computer(s) have problem(s) (or why are you here?), the logs from your computers will lack at least one, and maybe more, of the above tests showing similar results.

Your job, or mine, will be to read the logs, and interpret the failed test(s) as pointing to specific computer(s), and specific component(s) on those computer(s).