Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

My question may be pretty basic TCP/IP / router based, but I need to couch it in terms of a Winpcap application pingplotter that I have used.

One of the features I did use in my last place of work was to use this Win32 application PingPlotter to test TCP/IP packet loss and transmission times for packets of size say 2000bytes.

Now to enable this feature, one needs to use the Winpcap driver.

It does seem like a bit of black magic though, how can one do random TCP/IP packet loss testing to a remote server when a receiving application is not on the other side?

Is it just looking for packet tcp/ip packet ack/nack messages, and analysing the IP stability at a lower level of protocol analysis? Typing out my question I might be answering my own question, but I really don't understand any detail so it's nice to validate or be corrected.

My second part of the question is this: the tool is able to create nice graphs of the packet loss of my test tcp/ip packet to every hop on the tracert.

To the target server, which I know to be a SQL Server to which I can connect, it seemingly fails every packet, though all the hops of the tracert seem to deliver ok. Is this something I know I might expect if the machine has a operating system based software firewall of some description, that is regularly seen in practice?

I note that PingPlotter generally tests on port 80.

Does anyone else have any other suggestions how I might better test the client connectivity to the server? We are getting messages from the SQL Server client library saying that keep-alives are occasionally going missing, so I was wanting to set up some tcp/ip packet testing and draw a nice graph of packet loss and transmission times for a 1k packet, monitored overnight.

In my last place of work, I did this and found a lot of problems, but the failure to validate the tcp/ip packet sent to port 80 is a bit of a bugger, as it report 100% packet loss immediately, despite functioning as a working and reachable SQL Server.

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

Found this link about PingPlotter port usage. It seems that the TCP/IP "Ping" you are talking about just sends TCP SYNs on the specified port and waits for ACKs. So, if your server is not responding on port 80 (http), you might want to try the port the SQL service is listening on (1433 for MSSQL, 3306 for MySQL).

share|improve this answer
    
Thanks, on your prompting I tried a few different ports - 445 has seemed to work for me as the microsoft directory service. –  polyglot Jul 22 '09 at 10:02
add comment
  1. Do not use packet of size 2000 bytes for testing. 2000 bytes could be larger then MTU of some devices making them fragment / drop packets which wont give you clear idea of transmission loss just due to channel error.

  2. For monitoring packet loss from client to server in wireless networks with poor connectivity I sometimes just use ping. Linux ping command gives good summarization at end like

    --- www.l.google.com ping statistics ---

    10 packets transmitted, 9 received, 10% packet loss, time 8999ms

    rtt min/avg/max/mdev = 102.921/123.423/144.075/12.673 ms

So you can leave ping running overnight and when you end ping using Ctrl + C then you will be able to see packet loss percentage etc.

This is also not the perfect way as it could be one way problem in channel. So packets might reach the destination but for some reasons replies could get lost. In such cases running (on destination)

tcpdump -v -i eth0 'icmp'

to see if ping requests are even reaching the destination helps clear things.

If for some reason Linux client in not available try to install cygwin and use cygwin ping. It might be same as Linux ping and should tell you the statistics at end.

share|improve this answer
    
Thanks Saurab, the issue is that I've been able to test network stability by monitoring TCP/IP packet loss previously. I found in previous cases that testing icmp (ping) packet loss is not a sufficient diagnostic, so I am interested in anything people might have to say about this. –  polyglot Jul 22 '09 at 7:29
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.