Hello, Sorry, I am new to WireShark and was told it was the best tool to help determine my issue. I am getting very slow web page access. I have tested my internet connection with various online tools such as dslreports and a few others and they all come back very close, so I am guessing my internet connection is fine. So this makes me think I am having a issue with my router, Luxul XBR-4400. I have captured 10 minutes with Wireshark. Is there a way to export my data so I can attach it to this forum for help. Thanks JR asked 16 Oct '16, 07:27  DCBUS |
4 Answers:
I took at your trace file and found, well, something and nothing. First of all, your question is a bit vague for network analysis. It would be helpful to have a questions like this:
Your trace file shows TCP traffic to public sites IP addresses plus some backchatter. Both groups of traffic show noteworthy information. TCP TCP traffic goes to apple and other sites. I hardly find real problems here, except the speed. - There are no excessive retransmissions or small window sizes - No rejected sessions or really sluggish responses Still, the packet rate is probably not what you would expect: Open the trace file with Wireshark and look at your throughput using the menu Statistics -> I/O Graph. Next add a new chart by clicking on the plus sign in the lower left corner. Fill in the following properties:
Bring up the new chart by activating the checkbox on the left-most column and disable all other checkboxes. The resulting line shows a maximum throughput of 560 kBit/sec. Yes, in todays world that is slow. You might want to verify the link speed by visiting several web sites that calculate your download speed. Backchatter The backchatter from broadcast and multicast messages tells a different story. It looks like you have a rather unmanaged bunch of systems. Here is a short list of noteworthy symptoms, that is certainly not complete:
Hope that helps. Good luck. answered 19 Oct '16, 02:41  packethunter |
You would like to check to see if the problem exists only on the machine you are currently on, or on other machines too. e.g. your current device or any device. Next check without any antivirus/antimalware software. See if there's a difference. If you have the possibility, see if the problem exists with another router. answered 17 Oct '16, 02:49  SynAck Hello, Thank you for the reply. Yes, symptom is with all machines on the network. I also have tested without any anti virus turned on, same issue. What is the best way to post my capture so someone can view the output? Thanks Jr (17 Oct '16, 05:03) DCBUS 2
Look at my Comment to your Question. (17 Oct '16, 05:04) sindy What i forgot to ask, is this to any website or only certain websites? If it's only specific websites, could you post a traceroute to these websites? (If possible from at least 2 troubled devices) And like Sindy said, use any online cloud storage, like Dropbox, MS OneDrive, Google Drive, etc to share a pcap, so we can have a look ;-) (17 Oct '16, 05:30) SynAck Hello, It seems to be on most sites. I have done a traceroute on a few that seem to be the most latency, but route looks good. I am using Google DNS. Here is the link to the Wireshark capture, Thank you, JR (17 Oct '16, 06:03) DCBUS @SynAck, @DCBUS Your "answers" have been converted to comments as that's how this site works. Please read the FAQ for more information. (17 Oct '16, 06:19) grahamb ♦ To me it seems that all TCP sessions that have been initiated during the capture (i.e. you can see the DNS query and response followed by establishment of a TCP session and exchange of some encrypted information using that session) took less than a second, so I'd expect the lags not to be caused at network protocol level but at application level (i.e. by the application not asking for additional data fast enough, or not rendering the received data fast enough). So it would make sense to start capturing, go to a web site with no links to externally provided contents (such as advertisements), and stop the capturing immediately at the moment when the page is completely loaded (i.e. when the browser stops showing the "loading in progress" indicator). At best, you should be visiting that site for the first time after reboot, so that the fqdn to IP resolution would not be cached and thus the DNS query and response would be seen in the capture. (18 Oct '16, 08:39) sindy showing 5 of 6 show 1 more comments |
The "slow" website in this capture appears to be 162.125.34.129. There are 10 transactions, all using SLL encryption and all with the same profile - a single packet request of 882 bytes and a single packet response of 257 bytes. The timing of these transactions ranges between 30.24 seconds and 87.12 seconds. All of the time for each transaction is server time, that is, time spent inside the server waiting to be processed. We can tell this because the client's request packet is ACKed straight away (meaning that it must have arrived at the server) and then it is a long time before the server's response packet arrives. Since the capture was taken at the client, the network RTT is included in the above timings. The minimum observed RTT for that server was 63.7 ms. Note that what we think is the "server" may not be the real backend server. It may be a load balancer, transparent proxy, web front-end, etc. Meaning that the long "server" times may turn out to be timings due to other back-end activity of some kind. Given that all these transactions are identical in size, only you can know if they are relevant to your "slowness". answered 20 Feb '17, 23:11  Philst |
The easiest way to determine whether it's a network latency or a server-side latency is to look at the TCP 3-way handshake. 3-way handshake packets are quite small and thus won't get fragmented and as they're small, they'll pass through the network fairly quickly. Compare the delta time between the first [SYN] packet and the returning [SYN, ACK] packet. That will give you your rough RTT (Round Trip Time) which is the speed it takes a packet to traverse the network twice. Half of the RTT is the time it would take for the packet to get sent one way. So if you have a request sent to a server and a 9 second later reply from that server, but your RTT is only 160msecs, then subtract 160msec from 9 seconds and the remainder of time is the remote site. If the remote server is a front end (load balancer or other server) which connects to SQL DB servers or other processing servers in the background. That is where I would look, but you cannot capture that from the client side. It would have to be captured on the server side to pin-point where/what the issue is. It could be any number of issues. Cheers, answered 21 Mar '17, 00:39  wbenton |
This site has no own area for publishing capture files. Use Cloudshark or any plain file publishing service (Dropbox, Google Drive, Microsoft Onedrive, ...) and edit your question with a login-free link to it.
Other than that, are all web pages affected or just some of them? And do you use any anti-virus protection?