This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Hostel lan TCP retransmission and DupACK problem

0

I am at a college hostel. Internet service is provided by the college through HTTP proxies 10.1.1.18 and 10.1.1.19. My ip settings are

IP address: 10.8.1.250 Subnet Mask: 255.255.255.0 Gateway: 10.8.1.1

The hostel network consists of distribution switches which connect the computers in a very unstructured manner. The (main) hostel distribution switch is connected to gateway. The proxy internet was working fine until recently when internet speed went down drastically. There is no problem with the proxies as other hostels networks using the same proxies and same structure are working fine. Also, for the same reason, broadcast packets are also not a problem.

Ironically, ping to the proxies improved when the problem occurred, earlier we used to get 3-5 ms during peak hours, but now we are getting constant <1 ms. Maybe because of reduction in traffic.

There are no Computer Science students in our hostel, and we don't know much networking to solve it ourselves. What could be the problem? I started capturing packets after starting a download. I will upload the file as soon as i figure out how can it be done, until then here are some pictures

EDIT: Heres the capture file alt text

alt text

asked 25 Jul '15, 08:38

Obliterator's gravatar image

Obliterator
1115
accept rate: 0%

edited 25 Jul '15, 08:44

Have you taken the trace at the host 10.8.1.250? Wireshark is missing some packets sometimes. So the most probable reasson is that packets are getting lost between proxy and 10.8.1.250. Also the ping shows a timeout sometimes. Seems that packet loss happens here, too.

(25 Jul '15, 12:48) Christian_R

Yes. The loss is very high. Looks like a hardware problem. I will try changing the ports and checking the input wire after I get permission from hostel warden.

Here is the trace:

C:\Users\Obliterator>tracert -d 10.1.1.18

Tracing route to 10.1.1.18 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 10.8.1.1

2 <1 ms <1 ms <1 ms 10.0.0.1

3 * * * Request timed out.

4 <1 ms * <1 ms 10.1.1.18

Trace complete.

C:\Users\Obliterator>tracert -d 10.1.1.19

Tracing route to 10.1.1.19 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 10.8.1.1

2 <1 ms <1 ms <1 ms 10.0.0.1

3 * <1 ms * 10.1.1.19

4 1 ms <1 ms 1 ms 10.1.1.19

Trace complete.

(25 Jul '15, 13:40) Obliterator

The traceroute says nothing, whre the loss occur.To do this you need a couple of same traceroutes. If the packet loss only occurs lets say after the second hop, than you can start your search. But The loss could still hapen at the first hops. -> Just info.

Why are hop 3 and 4 identical to the host 10.1.1.19?

(25 Jul '15, 14:25) Christian_R

I did many traces and found that losses are fairly uniformly distributed at every hop. I suspect the problem is with first hop and the loss carries over to the other hops.

About identical hops. I don't know how it works but whenever the third packet to the proxy server(10.1.1.18 or 10.1.1.19) is lost, as in X ms X ms *, the hop repeats. This doesn't happen for hops other than the proxy server, or loss of packet other than the third one.

(25 Jul '15, 16:12) Obliterator

Can you provide a trace with the traceroutes inside?

(26 Jul '15, 01:33) Christian_R

One Answer:

1

Now I have looked a little bit deeper in your trace file and I am wondering why ARP Request for different subnets can be seen in the tracefile??? This is really strange to me, without deeper knowledge of your network.

And there could be duplicated IP Addresses for the following addresses: 10.12.121.5 (Cabletron(MAC: 00:E0:63:C2:70:7C) and Enterasy(MAC: 00:01:F4:A6:53:91)) and 192.168.1.1 (Cabletron (MAC: 00:E0:63:C2:70:7C) and Netgear (MAC: 20:E5:2A:E4:FC:CB))

This could be the failure if one of these addresses is a gateway. (Hottest tip so far).

answered 26 Jul '15, 13:43

Christian_R's gravatar image

Christian_R
1.8k2625
accept rate: 16%

edited 26 Jul '15, 13:43

Thanks Christian! Problem solved. Some new students had set their subnet masks to 255.255.252.0. We corrected it to 255.255.255.0 and its working smoothly now. Thanks for your valuable time.

Looks like strangers on the internet are more helpful than college authorities.

Cheers!

(27 Jul '15, 06:16) Obliterator