hi plz i want to know how i can use wireshark to measure packet delay& packet loss through network asked 04 Jan '11, 10:08  flower |
6 Answers:
What type of traffic are you looking at? Is it TCP? answered 04 Jan '11, 15:51  Paul Stewart |
Wireshark provide several ways of doing that, depending on the higher-layer protocols you are running on your network. For instance it reports on various TCP occurrences like duplicate ACKs or retransmissions that are indicative of packet loss. These are reported through the Analyze:Expert Info. If you are running RTP for streaming audio or video it is very useful for observing packet loss and jitter (which is variation in delay). These are reported in Telephony:RTP Wireshark currently only has limited ability to directly report on delay. It can be inferred though through looking at response between client and server. For instance by filtering on ICMP, you can also review the difference between packets (looking at the Frame details and "Time delta from previous displayed frame". More useful for you however might be to examine the TCP response time. In particular if you examine the SYN to SYN/ACK delay this is very indicative of network-only delay (as most kernels will respond to a SYN request with the highest priority). You will be able to see this if you look at TCP detail of the SYN/ACK packets and view the "RTT to Ack the segment". answered 04 Jan '11, 16:17  martyvis |
hi thanx everyone tried to help me but i need the accurate steps like from menu ...... go to option ....... i want to measure packet delay through real applications like video conference which uses UDP protocol i really need to know the details for doing that wait for you replies answered 05 Jan '11, 08:49 flower |
ok thanx again martyvis i will try to explain what i want to do i want a tool help me to measure the affect of network on data ttransfer from sender to reciever i know when use tcp used no data loss no packet delay but when using udp which is connectionless protocol so there must be an effect(loss packets - delay) the question is how i can measure this by any tool wireshark or any other program if you can help me with details this will be great from you thanx answered 07 Jan '11, 08:11 flower OK there are a few points to make. 1. You are asking about characteristics of the network 2. I think that possibly you don't understand why we have connectionless protocols In regards to the the first, if you want to understand how long it takes for an IP packet to traverse the network all you need is measure the round-trip time for a request and response, and divide by 2. As stated above it doesn't really matter whether it is ICMP, TCP SYN/SYN-ACK or DNS. As long you can account for the remote server processing time, you can remove that. (07 Jan '11, 15:24) martyvis Apart from any quality of service parameters that might exist on your network, all IP packets are treated pretty much equally. In regard to the second point, whether you use TCP or UDP to carry an application protocol depends on its requirements. You wrongly said that TCP had no data loss or packet delay, but this is not true. You use TCP if you want the transport layer to "repair" packet loss and try to maximise efficiency in doing that. UDP is used when packet loss isn't as important, or at least the application can easily recover. For instance DNS uses UDP. (07 Jan '11, 15:28) martyvis If DNS doesn't get a response within a short period, it just sends the request again, possibly to a different server. (DNS does use TCP for zone transfers - where integrity matters more). Voice and video also tends to use UDP because if a packet is lost, it is probably going to take too long to recover. In that case the appplication just "fakes it" by playing silence or maybe freeze-framing. Also delay isn't quite the problem unless it gets too long. Voice/video stream always have playout buffer to accomodate delay and jitter. Is your Q. in regard to a real-world problem or just for study? (07 Jan '11, 15:32) martyvis |
again thanx martyvis for your answer. my question is for studying a point with title Ways of hiding data sent over networks and vulnerability to the problems of network. for the first part which is Ways of hiding data is ok for me but about the other part which is vulnerability to the problems of network is ambiguous for me especially i haven't a good knowledge about these problems. which important to me is how i can measure this vulnerability to can make the practical part for my study all i understand is it depends on application(i.e if i transfer a file for example it use tcp so as i understant wrongly as you described to me so it will arrive with no vulnerability from network) so how i can apply my study to measure this vulnerability to the problems of network and which application i can use to acheive result for my study i don't want to lost your time but if you can help it will be very very useful to me answered 08 Jan '11, 08:22 flower |
I would say this is an even broader topic than packet delay. The thing is that everything is vulnerable to network packet loss. The question is how the protocols deal with that. TCP has it built in. Basically detection of loss packets and retransmission. However, that does not solve all issues. There could be a total outage or saturation in which case, the TCP stack can detect that and shut down the connection (and realize that the data was incomplete). UDP does not have this built in. However, protocols above the transport layer can have their own detection and retransmission. It all depends on the situation. I would recommend picking up a good book on TCP/IP like TCP/IP Unleashed (http://www.amazon.com/TCP-Unleashed-3rd-Tim-Parker/dp/0672323516) and/or Laura Chappel's Wireshark Network Analysis book (http://wiresharkbook.com/). The questions posed are more about protocols than Wireshark per se. Laura's book is good about helping to understand both. answered 08 Jan '11, 08:46 Paul Stewart edited 08 Jan '11, 08:46 I have to agree with Paul. It will definitely be worthwhile looking at some texts on network and application protocols. Apart from some college-level data communications books, you can also possibly read some of the RFCs for protocols like TCP and RTP. They generally try to describe the problems they are solving. (08 Jan '11, 19:06) martyvis Wireshark for a network engineer (or one who hopes to be), is analogous to a multimeter and an oscilloscope for an electrical engineer, or a microscope to a biologist. The tools provide visibility into the mechanisms, and often have some ability at even "expert analysis", but they will work better for you if have undertstanding of the fundamentals. The biggest problem of course is these tools only can really probe a single point, and they don't have visibility of the overall context. ( A multimeter doesn't tell you what current is flowing while you are measuring voltage). (08 Jan '11, 19:07) martyvis Luckily wireshark can build up some context, particular as it records data over time, and knows in general how hosts and protocols work. It could possibly to a bit better job at reporting on things like SYN / SYN-ACK response (something I keep contemplating trying to hack on). But at the moment it is what it is. (08 Jan '11, 19:08) martyvis |
You might want to take a step back and first understand what delay is, and how you would measure it. Delay is the time between when a packet is sent at one end and when it is received in the other. If you are only measuring at the received end, how can you know when the packet is sent, and hence calculate delay? This is the problem that Wireshark, and hence you as a user needs to face.
You seem to already understand that say your video conference is using UDP (and presumably RTP at the higher level). If this is the only traffic you were looking at, you cannot calculate delay.
You need some other point of reference. While Wireshark adds a timestamp on receipt, it doesn't know when it was sent. If you had a WS box at the sender and one at the receiver, you might think you could use timestamps at each end and compare. The problem with this is that it is hard to synchronise clocks accurately enough (in comparison to the normal delays you would expect). So the other alternative is to make an assumption that delay is symmetric (same both ways) and measure a packet going from the WS end to the other and watch for the response. Hence my comments on ICMP and SYN-SYN/ACK.