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

Always delay after 3x Dup Ack

0

Hello,

I think we have a Problem with our Firewall. Every time we request a new Webpage, we have a delay from 0.5sec to 8-10sec.

Here are the packages at cloudshark: https://www.cloudshark.org/captures/821b1f427f0b

Every time it's the same sequence: DNS, handshake, 3x Dup Ack and then there is the delay between package 14 and 15.

When I connect directly to the router of our Internet Provider, it's the same sequence, except the 3x Dup Ack and the delay. Then it's very fast and the Webpage is displayed directly.

So I think it's a Setting at our Firewall. We have a SonicWall NSA3500.

Does anyone know what Kind of Settings can cause this behaviour? Or perhaps it's a Network/Switch Setting.

Any help is appreciated.

Best Regards

Thomas

asked 02 Jul '14, 01:59

ThomasB's gravatar image

ThomasB
1111
accept rate: 0%

How was this captured? Every outgoing packet is in there twice, but those don't seem to be simple duplicates since the IP ID is different. Also, all outgoing checksums are bad, which suggests the capture was done on a system involved in the problem, which is not a good idea.

(02 Jul '14, 04:50) Jasper ♦♦

when i tried,it took 8.7 seconds to load(Using 3G)and delay was seen from ip.addr 85.13.146.55.It opened total 6 session.I dont think firewall is causing any delay but delay is from other end.Maybe you can capture on client plus on router simultaneously and see the pattern.

(02 Jul '14, 05:04) kishan pandey

@kishan: I tried it on 20-30 different webpages at different times. When I'm going through the firewall, it's always with delay and always with 3x dup ack's. And when I plug directly to the router of our internet provider it's always fast without dup ack's. I really tried a lot. @Jasper: What do you mean? The client opens 2 connections on different ports. That's a normal process for a client-server connections. I found out, that if I request this webpage a second time, I don't have the delay and the dup ack's, even if I delete the cache or/and restart the pc.

(02 Jul '14, 05:35) ThomasB

@ThomasB right, I shouldn't look at traces when I'm not yet fully awake :-)

(02 Jul '14, 05:41) Jasper ♦♦

Hi,it would be better if you capture from client and router end at same time to compare if firewall is making any difference.

(02 Jul '14, 06:27) kishan pandey

One more thing to notice is that all DUP Ack packets have ttl value of 63 whereas other packets it is 47.could be assymetric routing problem.

(02 Jul '14, 07:20) kishan pandey

I can't capture at the same time, because the router has only one Interface. Either I take it for the pc directly or for the Firewall. But I checked, how I said, many different Websites with the pc and directly after that I checked man Websites through the Firewall. So I'm very sure, that any Network device cause this error.

What I found out, the delay only comes up if there is a packet "TCP Retransmission". Sometimes I have only the 3x Dup Ack. But without "TCP Retransmission" there is no delay. Can anyone do anything with this?

(04 Jul '14, 00:57) ThomasB

Because of TTL: The packets I send have a TTL 63. The packets I Receive have TTL 47, because between the server and my pc are 16 hops, which countdown the number. I think that's normal.

(04 Jul '14, 01:45) ThomasB

in stream 0,if u see ttl in packet 5 it has ttl of 47 and in packet 10,11,12 it has ttl of 63.all of them source as 85,13.146.55

(04 Jul '14, 10:45) kishan pandey
showing 5 of 9 show 4 more comments

One Answer:

0

I think the problem is in the firewall not forwarding your ACK from the 3-way-handshake and the subsequent GET request.
alt text

Packet 5 is the SYNACK arriving with a TTL of 47 with ip.id==0000. This is the real SYN_ACK from the Linux server at 85.13.146.55 17 hops away. The RTT is 28.8 ms.

Packet #9 is your first GET request, sent with a TTL of 128 as the client is running on Windows.

Packets 10-12 are the triple dupacks, which come in with a TTL of 63. These come in from your Firewall with a TTL of 63 (behind your router). The first dump ack arrives with a delta of 52.8 ms suggesting it was initially triggered from the real server which did not receive your GET request, maybe not even your ACK terminating the 3-way handshake (6) as the ip.id is still 0). Linux will send incrementing ip.id once a tcp session is ESTABLISHED. Packets 11 and 12 are coming in too close (2, µs!) to packet 10 that they could really come from the server. So those are probably just a copy of packet 10 and are discarded (if they ever made it to TCP) by windows TCP layer. Otherwise we should have seen a Fast Retransmission.

The delay in sending out packet 13 is the retransmission timeout in windows as it has only seen 1 duplicate ack as per my theory above.

So I think the problem is that your firewall does not forward your ACK from the 3-way handshake and the first GET request.

Regards Matthias

answered 04 Jul '14, 23:53

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

Hi Matthias,to my knowledge Duplicate ACKs are sent when the receiver sees a gap in the packets it receives and about Ack server has sequence no.1957638664 in packet 10 which indicates that he has received a 3rd ack from client.question to me is client has just send a get request and if this doesnt reach to server after Retransmittion timeout client should had retransmitted it.why there is a DUP__ACK ?

(05 Jul '14, 04:30) kishan pandey

duplicate acks are sent when packets are received out of order. As this can't be the case - it is the first packet sent to the server - it must be some other mechanism that makes these dup acks appear. The point I was trying to make here it is NOT the server that is sending those triple-dupacks, it is the firewall (and maybe some other component tripling a single ack which makes it appear as 3 different acks.

Why would this happen? I'd ask SonicWall support if they can think of something. It might be a timing issue, the ack and get request coming in too soon and the firewall was not ready yet to create all its controlblocks for the new connection.

(05 Jul '14, 08:52) mrEEde

Hi Matthias,

thanks a lot for your answer, it sounds very proper. Here is a screenshot from our SonicWall. That are the only settings I found concerning TCP stuff. Do you see anything that fits to that problem:

alt text

Anyway, I will contact SonicWall support and hope they have an idea.

(07 Jul '14, 06:25) ThomasB

Hm, hard to recommend any changes here as I'm not a firewall expert.

Initially there are 2 simultaneous SYN packets flowing, maybe that triggers SYN Flood protection. So if you dare and have the power/privileges to change it, then you can give it a try disabling this.

(07 Jul '14, 09:34) mrEEde