TCIP

[hervé]

I don't know so much about TCPIP protocole, and I need some help to understand this behaviour :
My board at 192.168.167.205 replies to a PC at 192.168.167.83 but on frame #15 of this record there is an unnecessary ack for me. Can somebody explain it to me ?

[mark]

Hi Hervé

I think that your board is sending a TCP frame at frame number 14 at the same time as it is receiving the frame number 14. That must mean that it is sending the 8 bytes of data autonomously (not from within a callback, but generated asynchronously) - the reason why I suspect this is because it is not acknowledging data received in frame number 13 since its acknowledgment count is still acknowledging the previous data (134).

The ACK in frame 15 seems to be acknowledging the frame 13. This has acknowledgment number 267 but no data.

Therefore I don't think that there is anything wrong with the sequence. Note that, should unnecessary Acks be sent (for whatever reason) they will not disturb as long as their ACK counts are correct.

Regards

Mark

[hervé]

Hello Mark,

In fact that's also what I supposed. But there is effectively a problem in this TCIP sequence: My board send the two frames (15 and 16)with to different Ack number but with the same Sequence Number. So the windows socket's, on the PC, saw only the last one (So I think...) .
Why the sequence number of the frame 15 was not increased ?
I think it could resolve my blocking : The board is undefinitely waiting for an Ack of the frame 14; which will never occur.
And then reset the TCPIP Session.

What do you think of my point of view ?

[mark]

Hi Hervé

I don't fully understand the display of the sequence number with your packet-sniffer. It is displaying a range (?)
Possible the 0--8 means that it is being increased to 8, in which case following ACKs and data should also have the same value. It however looks as though the sequence number may be going back to 0 (?).

This would certainly not be normal behavior. But do make sure that you are never sending two TCP frames (when using simple TCP socket mode) without first waiting for the ACk to the first one. That means, never send further frames when an ACK is outstanding. When multiple frames are send in this case it will result in sequence number corruptions, which may be the root cause of the problem.

Regards

Mark

P.S. Using buffer TCP sockets allows the application to send multiple frames (using TCP windowing) but the down-side is that the socket then needs a RAM buffer, which obviously increases memory use.

[hervé]

Hi Mark ,
I still have a question concerning this problem : I effectively send the frame 27 of the following screen capture before the ACK of the frame 26 was send by the board, but why the ACK flag was set in frame 27, it look like it's an ack of the frame 26. So why a new ACK was sent by the µtasker stack ?

Thanks for your help.

Hervé

[mark]

Hi Hervé

There is an ACK sent in every frame of data. The ACK is acknowledging the data according to the ACK sequence count value.
This means that it is common to see an ACK sent multiple times with the same acknowledgment sequence count value. If only data is being sent the data will also always send an ACK to the last received data although no new data has been received.

This behavior also automatically corrects a lost ACK, whose transmission was corrupted.

Regards

Mark

[hervé]

Hi Mark,

Where can I got some flags, indicating that The TCP stack has still not yet acked a former frame from the Pc, to prevent me sending a new TCP frame, before this ack....

I found inside fnHandleTCP() whne we ask for an Ack, but how to do from the application level ?

Thanks.

[mark]

Hervé

There is no problem in sending additional TCP frames from the PC to your board. This is controlled automatically from the advertised TCP window so the PC will never sent too much data.

You only need to respect not sending multiple TCP frames from your board to the PC without first receiving an ACK to the first frame. In this case the event TCP_EVENT_ACK can be used.

Regards

Mark

P.S. Since a received frame is always immediately ACKed there will not be any value in being able to read the state of the ACKing mechanism.
In fact you will receive TCP_EVENT_DATA with the received data content. At this point in time no ACK has been sent - it will be sent in any transmitted data from the call-back or else once the callback has completed, when call-back doesn't send any data of its own (this is the reason for the return value APP_SENT_DATA so that no unnecessary ACK is sent when there was already data transmission).

[hervé]

Hello Mark, thanks for your explanations.

I'm really so confused, I'm not understanding completely this behaviour as my application is always waiting the TCP_EVENT_ACK before sending a new frame :

The PC sent two configuration frame 24 and 26.
The first one(24) was acked normaly on frame 25 by the TCP stack.
During the same time the second one(26) was sent with an ack for frame 25 in it, the board want to send a confirmation frame(27)
This is done with the same Ack number than the previous frame(25), because there was no data received at this time as you noticed.

Then the application layer wanted to send a second confirmation frame to the Pc, and wait TCP_EVENT_ACK which was already arrived from frame 26 and so is allowed to send a new frame.

So far I understood, this is a normal behaviour, but really confusing..

[mvaurelien]

Hello Mark,

Here is my question concerning the previous picture, according to the fact that uTasker see the TCP flow as below :

[-----------------PC-------------------]           [----------------LPC2387---------------]
seq   ack   frame number   length        direction   length   frame number   seq   ack
                        
177   25         24             133              >>>            
                                                       <<<       0                25            25   310
                                                       <<<       8                27            25   310
310   25         26             133              >>>            
                                                       <<<       0                28            25   443
                                                       <<<       8                29            25   443
443   33         30               0              >>>            

When uTasker receive the frame 26, does it know that the seq=310 is acknowledging the frame 25 and not the 26 ? Because, we are able to check it, thanks to the next ack number counting. It should be 25+8=33 if it had acknowledging the frame 27. But here it is 25+0=25.
The problem is that in our application stack, we are waiting for a tcp ack before sending the frame 28, but we are mistaking about the TCP_EVENT_ACK interrupt (get from the 26 but concerning only the 25). Thus we thought the the TCP_EVENT_ACK is acknowledging the 27 and we send the 28 (TCP ACK for the 26) the the 29 (PUSH ACK).

On the PC side, the frame 27 is received after the 26. And the 27 is never acknowledged. Does the PC think that it is a retransmission of the 25 already acknowledged ?
Because it should check that the lenght and the TCP flag (ACK/ PUSH ACK) are different between the 25 and 27.

I hope you understand my explanation and I thank you in advance.

[mark]

Hi Aurelien

I am sorry about the very late reply - I think that I have understood the question (although I believe that it should be "When uTasker receive the frame 26, does it know that the seq=310 is acknowledging the frame 25 and not the 26 27"

The event that you are waiting for is TCP_EVENT_ACK. This event is generated at one single SW location when a TCP frame is received meeting the following requirements:
1) if (ptr_TCP->ulSendUnackedNumber != ptr_TCP->ulNextTransmissionNumber) {
That means that we have not yet received an ACK to a frame that we have sent. If we haven't sent a frame yet (since last ack) any received ACKs will not get past this location and so there will never be an TCP_EVENT_ACK.
and
2) if (rx_tcp_packet.ulAckNo == ptr_TCP->ulNextTransmissionNumber) {
This means that the ACK number being carried by the TCP frame that is being received corresponds to out next sequence number. That is, it is acking outstanding data.

Your question seems to be about the frame 26. This is a TCP data reception which is not acking any new data (that is the ACK value has not incremented since previous ACKs).
There are two cases which depend on timing.
A) You haven't send any data
B) You have just sent data (the tx and rx are at about the same time)

In case A, the event will not be received because condition 1 above is not true
In case B, condition 1 above is true (you have send some data and are expecting an ACK) but condition 2 (above) is not true. The frame is carrying an ACK but it doesn't match the next sequence number that is expected. It will therefore be ignored.

Therefore I can't see that frame 26 can result in an event which is understood as an ACK to the transmitted frame 27.

Your frame 29 is incorrect, as you also know, because it should not be sent before an ACK with the ack number 33 is received. This is not until in frame 30. This frame is being sent with sequence number 25 (the same as in frame 27), which tells me that the TCP stack knows that previous data has not yet been received and so it considers it to be a repetition. The same is true for the PC that receives this frame - it will also consider it to be a repetition of the frame 27. It will probably ignore the content since it has already received the data before.

Based on the logic above I can't explain why your application is sending the frame 29 although there seems no possibility of having received a TCP_EVENT_ACK after frame 27 was sent.

Note that you may receive the event TCP_EVENT_PARTIAL_ACK in the case B. This is because there is outstanding date but the received ACK is not acknowledging it all. TCP_EVENT_PARTIAL_ACK should always be ignored by a simple TCP socket so be sure that this is the case in your callback - never interpret it as an ACK!!

Does this help in any way?

Regards

Mark

[mvaurelien]

Thank you so much. We used to interpret PARTIAL_ACK as an ACK...so yes, your explanation help us !