Hi, 1) what is the meaning ECN, CWR ? Is it related to bandwidth congestion ?
2) the traffic is normal and no complain this time...but we can see packet reset at the end of tcp stream.. is it normal server just reset the connnection ? -====================================================== one more question...Why there was TCP Suprious transmission below... asked 07 Nov '16, 23:43  suarez123 edited 08 Nov '16, 01:03 |
2 Answers:
The reason for the reset is the ssl encryption alert. But ECN and CWR Bit sometimes causes problems with firewalls or older stacks. answered 08 Nov '16, 00:38  Christian_R edited 08 Nov '16, 11:45 showing 5 of 8 show 3 more comments |
ECN and CWR are related to bandwidth congestion, but in a SYN or SYN/ACK packet they're just parameters to tell the other receiver of that packet that it's a mechanism understood by the sender. So sometimes you see a TCP handshake with those two flags, but that doesn't mean there is congestion. Congestion would be signaled by layer 3 devices during data transfer, which should result in the sender slowing down it's data rate, but as far as I know that never happened or worked well - the congestion happens to fast for the notification to be efficient. And yes, a reset at the end of a connection is nothing unusual, as it frees up resources quicker than a FIN/ACK FIN/ACK teardown. You can tell that it's not a critical connection abort because of the encrypted alert that is sent just before the reset packet - it's the signal of the sender telling the other side to expect connection reset (otherwise attackers could use reset packets to abort encrypted sessions between two other devices). With the alert the reset is validated to be from the original sender. answered 08 Nov '16, 01:04  Jasper ♦♦ edited 08 Nov '16, 11:44 Christian_R Thanks Jasper... TCP spurious transmission related to application or bandwitdh congestion ? (08 Nov '16, 07:34) suarez123 What is the root cause of first screenshot no "client hello " and no " application data " like second screenshot.. (08 Nov '16, 07:36) suarez123 Spurious retransmissions are only slightly related to congestion since it basically means that data was retransmitted that had been acknowledged by the receiver. So that ACK must have gone lost on the way to the sender of the data, which made him think that he had to send it again. Which could be caused by congestion, but it could also have other causes. The first screenshot looks like it has trouble setting up the connection, so it's more TCP connection stuff in those packets than in the other one that works better. (08 Nov '16, 17:30) Jasper ♦♦ |
Thanks Christian_r... how to check at the firewall ?
Normally the packets are filtered out, if the firewall has problems with ecn and cwr. So you can trace in front and behind the fw or just watch the fw logs.
Great Christians_R...i have just add 1 more question..Thanks
Above screenshot i capture BEFORE the firewall.. the connection via lease line...router connect to switch...i mirror the switch port router....is it because client's firewall ( 10.12.229.56 ) issue ?
Well the ecn and cwr bits makes no problem in your session. As your session works fine. The encryption alert seems to be your problem here.
Well hard to tell with that screenshots: But it seems that the Client Hello is getting lost or at least it has not been acked. And no DUP_ACK has been send so far.
For that reason the Client_Hello will be retransmitted again. It is more a Retransmission of time. But Wiresharks remarks it as a Spurious_Retransmission, as we haven´t seen a DUP_ACK so far.
thanks Christian_R.... What is the root cause of first screenshot no "client hello " and no " application data " like second screenshot..means got issue for first screenshot ?
Please forget for the moment ECN and CWR they are just proposal flags inside the 3-Way Handshake.
The root cause of the first screenshot, we can´t see. We just can see what has happend here, the ACK of the 3-way handshake will be late.
Maybe a look inside the trace will make the analysis more reliable.