Wireshark catching a packet common errors occur

Turn from here

1. TCP Out-of-order( problem with TCP)

Answer:

1), there should be many reasons. But mostly network congestion, resulting in sequential packet arrival time is different, delay is too long, or packet loss, need to regroup data units because they may be different paths to reach your computer.

2), CRM IT colleagues last week to react with me a problem, by their customer service system by mail host to send to the customer's letter, often there will be sent the failure of the problem, check the Log, found that the normal mail after the host receives DATA is completed will record the size of the message received, And then start the subsequent delivery of the processing, but these problematic to send, will occur when DATA is not delivered, the server records have been read to EOF, and then end the connection, so this letter is not smooth to the Server.

A preliminary look at the elimination is a timeout problem, because the connection time has not reached the setting of the connection timeout time, because the CRM system is written by the outside manufacturers, in order to clarify the problem I have to catch a packet to see if the user end sent out to end the instructions.

Grabbed it. The results are as follows:

The entire message transfer process, including a large number of TCP retransmission or Segment Lost, to later run out of TCP Out-of-order, seems to be a network problem, the network on the TCP Out-of-order suggestion is that some Pa Cket may be Lost, so the re-transmission is caused, the other may be because the Client to the Server has two network paths, such as the Load Balance, such as the architecture, so if two packets go different paths, late delivery of packets than the arrival of early delivery, will occur Out-of-order.

Therefore in the assertion that there may be network, coupled with the network card on the CRM system colleague is to make a virtual, and then ask him to take away Bonding only with a single sheet run, the problem does not exist, the observation of traffic is also running than the original two pinch up the Virtual single-sheet run high, so m$ in Bonding on the network card is not what needs to be adjusted on it, at least to find out the cause of the large number of delivery failure is good.

2. TCP segment of a reassembled PDU

Answer: 1 in connection with the establishment of the time, the SYN packet will be each other TCP maximum packet length, in the LAN is generally 1460. If the packet sent is longer than the maximum packet length, it will be fragmented, and the packets that are fragmented are marked "TCP segment of a Reassembled PDU ", for reference, see that the SEQ and ACK of the marked package are consistent with the original package:

2) last week in the company encountered a problem, with Wireshark capture system to the network management reported data found that there are many messages are identified as "TCP segment of a reassembled PDU", and each piece of the message is 180Byte, at that time to see such an identity, Think is the IP message Shard, thought the System interface MTU value for the setting is small, through the command query found is 1500, has not been reset, at that time a little thought.

Back to check, found that their understanding is wrong, "TCP segment of a reassembled PDU" refers to the IP layer is not a shard, IP shards in the Wireshark with "fragmented IP protocol" to identify. A detailed look, found that "TCP segment of a reassembled PDU" refers to the TCP layer after receiving the upper chunk of the packet decomposition into a paragraph after the issue. So there is a doubt that the TCP layer can completely send a large segment of the message to the IP layer, so that the IP layer to complete the segment, why the TCP layer to divide it? In fact, this is determined by the TCP MSS (Maximum Segment size, the maximum message length), TCP in the TCP header of the first message that initiates the connection through the MSS this option to inform the other side of the maximum message can receive (of course, this size is the size of TCP payload), This value on Ethernet is generally set to 1460, because the 1460Byte net charge +20byte TCP header +20byte IP Header = 1500 bytes, exactly in line with the link layer maximum message requirements.

How do you determine if a message is a "TCP segment" after it is received? If there are several messages with the same ACK sequence, and the sequence number of these messages are different, and the latter sequence number is the previous sequence, plus the previous message size plus 1, it must be TCP segment , it is not possible to determine when there is no ACK flag.

Since the received TCP messages are all 180Byte segment, then should be negotiated when the PC side told the MSS for 180Byte, as for why this, can only wait to confirm after the packet after the MSS to check the problem. In addition, there is a situation can also cause this problem: the system is tested because the MTU is 220Byte and set MSS to 180Byte, but this situation can now be excluded, because previously said, has been queried the MTU value is 1500.

3. TCP Previous segment lost(TCP previous shard loss)

Answer:

(1), "TCP Previous segment Lost" Errors is not "fatal" errors. They simply indicate the sequence number in the arriving packet is higher than the next-expected sequence number, IND Icating that at least one segment is dropped/lost. The receiving station remedies this situation by sending duplicate ACKs for each additional packet it receives until the s Ender retransmits The Missing Packet (s). TCP is designed to recover from this situation, which are why the image is downloaded correctly despite have a (briefly) Missing packet.

If you were getting a large number of lost packets, then there was likely a communication problem between the sender and Rec Eiver. A Common Cause of this is un-matched duplex settings between the PC and the switch.

We lab recently upgraded to Ethereal 0.10.14 with WinPCap 3.1.  If I Remember correctly, we had previously B Een using 0.10.2 with WinPCap 3.0.  However, since the upgrade we have been noticing several issues.

The first issue is with "TCP Previous segment Lost" and "TCP CHECKSUM incorrect" messages appearing in the Packet Listing window.  We don't remember seeing these in the previous version of Ethereal, or at least not nearly as many as We ar E Seeing now.  For example, one task for the student instructional part of the lab involves visiting a website Contai Ning images and observing the network activity.  after the both GET requests is sent for the images, it's not UN Common for one image to being returned with a typical OK response packet, but the response packet for the other image wil L be displayed as "TCP Previous segment lost."   However, both images is downloaded and displayed perfectly fine in the browser.  I would think that the Segme NT lost error would mean the object wasn ' t returned correctly and shouldn ' t is able to is displayed, but apparently that I s not the case.  (the cache had been cleared if this is performed, so it is not defaultingTo a local copy of the image.)

Another problem we ' ve been noticing is a some packets simply aren ' t displayed in the Packet Listing window, even when t  Hey is obviously received. Using the same example as above, after the both GET requests yes sent for the images, it's not uncommon for one image to B  E returned with a typical-OK response, but the other response would not appear.  Yet both images is successfully displayed in the browser. Is this a problem with Ethereal not detecting the packets?

I ' m not sure how typical the IS, but we seem to be experiencing these issues often with 0.10.14 while we never do with 0  .10.2.  Could It also be a issue with WINPCAP, and not necessarily Ethereal? I ' m just trying to find some answers as to why we are seeing a sudden abundance of TCP related errors and uncaptured Packe  Ts. Thanks.

(2), I have a network client application this runs fine while I am debugging (no TCP errors),

But when I run the release version, it runs incredibly slow. It runs as a series of

Transactions, where each transaction are a separate connection to the server. Wireshark

Analysis have determined that about 50% of all transactions involve the series:

TCP Previous Segment Lost

TCP Dup ACK

Rst

The RST consumes 3 seconds per transaction, which is a Big Deal. So to prevent it, I must

Prevent the initial "TCP Previous Segment Lost" (which seems, on the surface, to merely be

A time-out on a particular segment).

The following clip, the SYN packet suffers from the "TCP Previous Segment Lost" condition.

0.000640 seconds seems like too short of a time to declare this condition, as many previous

Successful transactions took much longer to be successfully syn-ack ' ed.

Can somebody explain "TCP Previous Segment Lost" In this context to help me troubleshoot my

Problem?

Any help would is appreciated.

Here is a clip of a problem transaction:

4. tcpacked lost Segment(TCP response lost)

5. TCPWindows Update(TCP window updates)

6. TCP DUP ACK(TCP repeat Reply)

TCP may generate an immediate acknowledgment (a duplicate ACK) when the Out-of-order segment is received. This duplicate ACK should is delayed. The purpose of this duplicate ACK are to let the other end know that a segment be received out of order, and to tell it WH At sequence number is expected.

When a problematic shard is received, TCP immediately generates an answer. This same ACK is not delayed. The intent of this same response is to let the peer know when a shard is received, and to tell it what serial number it wants to get.

Since TCP does not know whether a duplicate ACK are caused by a lost segment or just a reordering of segments, it waits for A small number of duplicate ACKs to be received. It is assumed so if there is just a reordering of the segments, there would be are only one or both duplicate ACKs the reordered segment is processed, which would then generate a new ACK. If three or more duplicate ACKs was received in a row, it was a strong indication that a segment had been lost. TCP then performs a retransmission of any appears to being the missing segment, without waiting for a retransmission timer T o expire.

7. TCP Keep Alive(TCP Keep-Active)

In TCP, there is a keep-alive mechanism to detect dead connections, the principle is simple, TCP will be idle for a certain time after the sending of data to the other side:

1. If the host is available, the other party responds with an ACK response, which is considered to be alive.

2. If available, but the application exits, the other party sends an RST answer, sending a TCP undo connection.

3. If reachable, but the application crashes, the other side will send fin messages.

4. If the other host does not respond to an ACK, RST, continue sending until the timeout expires and the connection is revoked. This time is the default

of two hours.

Uses WinSock2;

Procedure Tform1.idtcpserver1connect (Athread:tidpeerthread);

Type

Tcp_keepalive = Record

onoff:cardinal;

keepalivetime:cardinal;

Keepaliveinterval:cardinal

End

Var

val:tcp_keepalive;

Ret:dword;

Begin

Val.onoff:=1;

val.keepalivetime:=6000; 6s

val.keepaliveinterval:=6000; 6s

WSAIoctl (AThread.Connection.Socket.Binding.Handle, ioc_in or Ioc_vendor or 4,

@Val, SizeOf (Val), nil, 0, @Ret, nil, nil)

End

——————————————————–

The KeepAliveTime value controls how often TCP/IP attempts to verify that idle connections are intact. If there is no activity during this time, the keep-active signal is sent. If the network is working properly and the receiver is active, it responds. Consider reducing this value if you need to be sensitive to lost receivers, in other words, you need to discover the missing receivers faster. If the number of idle connections that have been inactive for a long time is more frequent, and fewer receivers are missing, you may want to increase the value to reduce the overhead. By default, Windows sends messages that remain active if there is no activity in an idle connection for 7200000 milliseconds (2 hours). Typically, 1800000 milliseconds is the preferred value, and half of the closed connections are detected within 30 minutes.

The KeepAliveInterval value defines the frequency at which TCP/IP repeats the Keep-active signal if the response to the keep-active message is not received from the receiving party. The connection is discarded when the continuous sending of a keep-active signal, but the number of times the response is not received exceeds the value of TcpMaxDataRetransmissions. If you expect a longer response time, you may need to increase the value to reduce the overhead. If you need to reduce the time spent verifying that the receiver has been lost, consider reducing the value or TcpMaxDataRetransmissions value. By default, Windows waits 1000 milliseconds (1 seconds) before resending messages that remain active without receiving a response.

KeepAliveTime is set according to your needs, such as 10 minutes, note to convert into Ms.

XXX stands for this interval worth the size

8. TCP Retransmission(TCP retransmission)

As a reliable transport protocol, Transmission Control Protocol (TCP) is acknowledged when the sending host needs to receive a packet from the target host. If the sender does not receive this acknowledgment within a certain amount of time, it acts under the assumption that Packet did not reach its destination and retransmits the packet. If the sender does not receive a certain amount within the time, confirm that it behaves under the assumption that the packet does not arrive at its destination, and forwards the packet.

Wireshark catching a packet common errors occur