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

Syn with ECN flag set on certain port number

0

I'm facing issue with an embedded device webpage. Webpage of the device works fine when used directly in local intranet but when its behind one corporate firewall it becomes extensively slow. When i wireshark the packets i found

  1. Client PC sends packets in different source port but embedded devices receives it in different port
  2. Firefox opens 6 concurrent connections to the embedded device and those ports open and work normally
  3. after 1-2 second i see SYN request with ECN flag set. when ECN is set no communication from Embedded devices it retries on SYN.
  4. My question is why it flags ECN in SYN only after a while and only on specific ports
  5. I also observed the gateway/proxy inside network slows the packet

Please help me with this i'm trying to figure this out..any help will be greatly appreciated. Please let me know if you need wireshark captures on both ends i have captured at both ends in parallel

asked 12 Feb '14, 05:26

Sumeet's gravatar image

Sumeet
11114
accept rate: 0%

edited 12 Feb '14, 06:20

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237


2 Answers:

1

but when its behind one corporate firewall it becomes extensively slow.

well, that's a first sign for the source of the problem ;-) If it's a firewall with content inspection for HTTP (AV, URL filter, etc.), it's absolutely 'normal' that the access through the firewall is slower than in the local network. How much slower, depends on the capacity of the firewall, the firewall configuration, etc.

Client PC sends packets in different source port but embedded devices receives it in different port

that's the second sign for the source of the problem. Either there is a transparent proxy on the firewall (see content inspection above) or the port change is the result of a NAT operation. But then you should see a different source IP as well.

My question is why it flags ECN in SYN only after a while and only on specific ports

hard to answer. It depends who sets the ECN flag. If it's the client (browser), it would be kind of strange. If it's the firewall (or a QoS or WAN acceleration device), I would understand it for certain conditions.

I also observed the gateway/proxy inside network slows the packet

Sure. Every proxy will slow down the connection, compared to a direct local access, as the proxy might also have content inspection (AV, URL filtering) enabled, which obviously costs some time to perform. How much time it costs, depends on the capacity of the proxy, the proxy configuration and where the proxy is placed in your network.

lease let me know if you need wireshark captures on both ends i have captured at both ends in parallel

Go ahead and post them somewhere (google drive, dropbox, cloudshark).

However, based on your description and my experience, I recommend to talk to the firewall/proxy admins how to solve the problem by configuring exceptions for your web gui access.

Regards
Kurt

answered 13 Feb '14, 14:55

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

We are developing this embedded device and question what i have is our current webserver on device doesn't respond to any of the SYN with ECN flag set even the flag is not set at IP level. So we need your expert opinion should it respond to it or not and why its set? other SYN doesn't have it...please look at the wireshark capture and suggest. Again many thanks for your help... https://www.dropbox.com/s/euslq9yac6gmaxn/WireShark%20FEB%2010%20%20Capture.pcapng please let me know if you have any problem accessing the file..

(13 Feb '14, 15:44) Sumeet

All clients have the same IP address, so there is either NAT or a (reverse or transparent) proxy in place.

The frames with the ECN flag set have a different IP TTL and IP ID sequence, so it's likely that it's two (or) more different systems.

So, it's rather unlikely, that your firewall/proxy modified those frames and set the ECN flag. It's the (external) clients that do it on their own, because their TCP/IP stack is configured in that way.

As a result, you'll have to support connections with the ECN flag on your embedded device if you want to support those clients as well. As an alternative, you could implement a reverse proxy in front of the embedded device, that handles those connections, but I guess that embedded device is meant to be working on its own in the wild, so a reverse proxy is probably not an option.

(14 Feb '14, 00:45) Kurt Knochner ♦

Please let me know if you need wireshark captures on both ends i have captured at both ends in parallel

O.K. can you please post both capture files?

(15 Feb '14, 10:55) Kurt Knochner ♦

1

The ip addresses 144.191.148.4/5 are actually a NAT devices. In this trace there are at least two different clients coming from the same NATed IP address.

  • Windows client coming in with a TTL 0f 100 and a windowsize of 8192
  • Linux client (45888) coming in with a TTL of 44 and a windowsize of 5840 alt text The Linux client has ECN,CWR set in its SYN packet which your server silently discards. Not responding to those SYNs might not be a good idea if those requests are validly coming in. It might howerver also be a mo nitoring device probing your server. So if you reply without those bits being set you will at least get a tcp session and see what this linux client is trying to do...

As for the 'extensively slow' problem: You don't support window-scaling in your SYN_ACKs which over long latency connections will be causing performance degradation as the advertized windowsizes will never exceed 64k.

answered 13 Feb '14, 22:43

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

Thanks for explanation so just to understand better the SYN with ECN bit set are not valid/genuine http webpage request its some kind of probe which network infrastructure is trying to do [Linux requests]? Thanks again for your help

(14 Feb '14, 04:59) Sumeet

If you know your clients are not on Linux, then it must be something else.

The fact that after the failing retransmissions of the linux SYNs the client ip address changes to its "twin brother" 144.191.148.5 makes me think it might be a loadbalancer that checks for availaility and then decides that it doesn't have connectivity so better hand off the next requests to the other NAT device ...

(14 Feb '14, 05:30) mrEEde