I'm currently preparing for WCNA exam, I'm half way through the book "Wireshark Network Analysis second edition" on page 254, in chapter regarding TCP, laura (the author) has asked a question at end in exercise section which is very appealing and at same time I have no clue how to answer. The crux of it "using trace-file how can I tell where the location of wireshark was either downstream (closer to host receiving packets) or upstream (closer to host sending packets). This is in regard to packet loss." How can it be done? Question from book "Does this connection support SACK? Does this connection support window scaling? The TCP Selective ACK option is used in packet 136. What do the left and right edge values indicate? In packet 679, what sequence number is 10.0.52.164 waiting for from 61.8.0.17? Is Wireshark downstream (closer to the client receiving the data) or upstream (closer to the TCP host that is sending data) from packet loss?" asked 12 Jun '15, 12:18  lazerz edited 14 Jun '15, 06:04 |
4 Answers:
So in a TCP packet loss situation you will see retransmissions. But will you see the original packet? Or should I ask where will you see the original packet? Sorry I am trying to lead you to the answer rather than giving it directly. Can I ask how your studying is going? I am also studying for the WCNA, I have completed the books and the on-line material and most of the labs. Good luck. Now the answer, but its rot13 encoded, so you can choose to read it when you are ready; Vs lbhe jverfunexvat orsber gur cnpxrg ybff, gura lbh jvyy frr obgu gur bevtvany cnpxrg naq gur ergenafzvffvba. Vs lbh ner nsgre gur cnpxrg ybff lbh jvyy bayl frr gur ergenafzvffvbaf. answered 12 Jun '15, 14:04  chillypenguin showing 5 of 6 show 1 more comments |
Fairly obviously you're looking for some visible difference in the captures depending on where it's been taken. Try to think about what changes in the packets might be visible as you move from the sending host to the receiving host. Is there something in the packets that changes as it traverses the route from the sender to the receiver via intermediate hops? answered 12 Jun '15, 12:44  grahamb ♦ I have seen the trace file in terms of conversations, endpoints under statistics option and see the only communication is between host A and B only, no intermediate device were listed. Even so no icmp prot detected as well. (12 Jun '15, 13:38) lazerz here is the link to trace-file http://www.filedropper.com/home_6 (12 Jun '15, 13:49) lazerz Wireshark does only show the two endpoints as that's all that's available at any point in the route. However, what MUST each intermediate router do to something in the packet as it transits that router from the sender to the receiver? (12 Jun '15, 14:36) grahamb ♦ Yes, its TTL, but then there is no icmp ttl expired messages or more the field values are both static for each host. (13 Jun '15, 01:15) lazerz Please let me know if my understanding is correct using the time column set for "time since last display packet" is see 1.333 delta between SYN and syn/ack response, so If i was more closer to host sending this packet would the response comes more fast considering there is problem with network or congestion? (13 Jun '15, 01:23) lazerz I wasn't thinking of ICMP TTL exceeded, but the actual TTL in the packet that is being sent from sender to receiver. Although absolute values are hard to determine, the TTL will be higher the nearer the capture is made to the server. The absolute value is difficult as different OS's have a different default value. One table of default values is here. If you can see a complete request\response from client to server and back, i.e. SYN and SYN ACK then looking at the delay between them can also be a clue, a shorter delay is closer to the server. (14 Jun '15, 01:56) grahamb ♦ Yes true indeed. This is how I worked around the problem.The way I was able to answer this, was as you said got some help from laura heavily commented trace-file. In the handshake process, you can establish that there exists an issue of link latency ( see the round trip time values). See frame 5 in home.pcapng you would see the client waited 155 ms or more for a response to come from server. Now here is the catch, considering if the wireshark was present on the server side,the delayed would never be seen in terms of response (server) right? the delayed in that case would be ACKs coming from the client side. Finding delta time between server last send data to client and response ACK from the client. A SYN/ACK packet for a wireshark installed on server wouldn't ever have to wait for 167 ms considering there is pre-exisining path latency issues. This is how and why I say that wireshark is on the client side not on server side. Please add anything to this analysis ,i'm open to your views/suggestions. (14 Jun '15, 06:08) lazerz Sometimes you do see delays on the server side, as it may be processing the request, but in the case of frame 5\6 the ACK in 6 will be handled by the TCP stack on the server so no processing delay is likely to be involved. To remove server processing (or client for that matter) concentrating on things such as the 3 way handshake which only involves the TCP stacks gives a clear indication of RTT. (14 Jun '15, 09:08) grahamb ♦ showing 5 of 8 show 3 more comments |
Hi, just a quick Info from what I understood when doing this: The question was where was wireshark in regard to packet loss, the answer lies in the sequence analysis of a retransmission and is not really as complicated as it seems.
If you see the original + retransmissions you are upstream, if only retransmissions, you are downstream. This was also not very clear for me until I got the Chappell University pass where this is then explained in full. (Core 2 Part 7 TCP Loss and retransmissions) It's expensive, but well worth the money. answered 15 Jun '15, 03:56  DarrenWright edited 15 Jun '15, 04:02 |
"Is Wireshark downstream (closer to the client receiving the data) or upstream (closer to the TCP host that is sending data) from packet loss?" answered 14 Jun '15, 08:44  mrEEde edited 14 Jun '15, 08:47 In the case illustrated, the original SYN TTL is 64 which is one of the cardinal values, and the SYN, ACK is 55 confirming that it was most likely taken on the originator of the SYN, in this case the client. (14 Jun '15, 09:01) grahamb ♦ Hi Graham, cool. Learning is fun ;) I never really bothered to think about using the TTL for this.. Filed under "good to know" A quick question that may require a separate thread.. is the RTT time from NIC out to NIC in or does it include the time spent Buffered / going up the stack as well? (29 Jul '15, 03:13) DarrenWright RTT is calculated using the packet timestamps. The accuracy of the packet timestamps depends on your capture mechanism, so it outwith Wireshark. (29 Jul '15, 04:31) grahamb ♦ |
Thanks chilly:)Preparations are fine so far. I really wish I can take more time from job for the end-chapter exercise they teach so much.
Interesting, you mentioned about labs? Is there a separate book or manual for lab work If yes please guide me through. I know that there is this 300 questions book for exam prep haven't read it yet.
For the answer thanks for old skool encryption:) I'm afraid reading your response I still can't say it answer the question. Did you view the trace file I hot-linked above? Best to move forward contact me a.alii85 at gmail dot com.
I have just responded via e-mail, with a more detailed tutorial of how to obtain the answer.
@chillypenguin,
Your answer indicates the location of the capture against the location of the hop that's dropping the packet, I'm not sure that's what the original question asked, i.e. is the capture closer to the sender or receiver.
My interpretation of the question, was where the the capture being taken, up or down stream of the loss.
did you got the email i send you?
@grahamb please see the question review.