SiTCPに関する情報を共有するためのフォーラムです。この目的に反しない範囲で、質問、コメント、回答などご自由にご投稿ください。
This forum is for sharing information about SiTCP. Please do not hesitate to post any questions, comments or answers within the scope of this purpose.

no TCP_CLOSE_REQ

投稿日時 2013/8/29 13:59

aokim

We are using the SiTCP on Spartan-6 for 100-MHz 32-ch FADC system. Recently, we have noticed that the TCP_CLOSE_REQ seems to be missing. Does anybody know about any tricks that we need to make it work?

Here are detailed descriptions what we observed:

  1. After the reset of the system, we can ESTABLISH the TCP connection to the SiTCP from a host PC.
  2. Data transfer by using "nc" command on the host PC works fine at this moment.
  3. Then, we cancel the "nc" by typing ctrl-C on the host PC. It changes the TCP status to FIN_WAIT_1. Note not TIME_WAIT.

    • we confirmed that TCP_OPEN_ACK still stays H in this step.
    • we also confirmed that TCP_CLOSE_REQ does not asserted yet.
  4. Now, we start the "nc" again. The TCP status for this new nc process stays SYC_SENT, and never becomes ESTABLISHED.

  5. Regardless to the strange status of TCP connection, if we send data to SiTCP, they are transferred to the host PC, and the TCP connection status changed to ESTABLISHED.

It seems to me that the SiTCP does not properly receive-and -respond to the FIN from the host PC.
Perhaps, SiTCP does not always assert TCP_CLOSE_REQ when it receives FIN, but check some other conditions or states of other input wires.

Do anybody know what are these conditions?
I really thank you for any information related to this issue.


投稿日時 2013/8/30 13:57

bbtech

We are checking this behavior. Please wait for a moment.


投稿日時 2013/9/3 14:23

knaruse

We have been checking the SiTCP library and tested it,
but same condition never be happened.

I need more information with this problem.
I have to ask a few question.

  1. Is this event happens in the latest SiTCP Library? Latest version is V7.0.
  2. How fast is your interface speed?
  3. How fast is your system clock frequency?
  4. How often that TCP_CLOSE_REQ is not react?

投稿日時 2013/9/17 20:06

aokim

Thank you for the response, and I am sorry to be late to answer you.

We are currently busy for the coming JPS meeting. Please give us another week to get answer to your questions.

Best Regards


投稿日時 2013/9/24 14:40

minhtruong

Dear Mr./ Ms. knaruse,

I am student of Aokim-san, I would like to answer your questions about our FADC system:

  • The SiTCP library is the last test version, I download it from this webpage and it has the name "XC6SSiTCPlib16k_70.zip"
  • The interface speed is 100Mbps
  • The system clock is 100MHz
  • TCP_CLOSE_REQ is usually not react

  • When you checked the SiTCP library, do you use the cycle trigger or manual trigger - by your hand?
    We make the trigger by manual trigger, using the gate generator and push the "Start" button on the gate generator.

  1. at first trigger - by push "Start" button on the gate generator, data can transfer as Aokim-san said in previous.
  2. after that we cancel by type "Ctrl-C"
    TCP_OPEN_ACK still stays H in this step.
  3. type nc command again to take data
    TCP_OPEN_ACK still stays H in this step.
    Data can not transfer
  4. make a second trigger by push "Start" button on the gate generator and wait some second
    TCP_OPEN_ACK become ESTABLISHED
  5. make a third trigger by push "Start" button on the gate generator
    TCP_OPEN_ACK will stay H
    data begin transfer to PC

This issue you can see when you make a trigger one by one, please do not use the cycle trigger

Please check it again and we happy to see your comment and really thank you for any information related to this issue.


投稿日時 2013/9/25 18:27

knaruse

We are checking the system by using evaluation board of Xilinx SP601.
But nothing has confirmed abnormal with that situation
(system clock 100MHz, interface speed 100Mbps).
It is hard for us to build the same situation.
Because we do not know the what the trigger is.
Also we don't know the environmental situation in using the gate generator.

We can not promise you that it will identify the phenomenon when the problem occur.
But if you captured the packet with the WIRESHARK,
this might be telling you what is the cause of this,
when the TCP_CLOSE_REQ is not appeared.

Best Regards,

knaruse


投稿日時 2013/9/27 11:29

minhtruong

Dear Knaruse-san,

Thanks for your comment,
I already see the Xilinx SP601 in the webpage, but we do not have this evaluation kit in our lab. We can buy it and test our firmware, but it takes time, we will try to do it.

Best Regards,

Minh Truong


投稿日時 2013/9/27 18:16

knaruse

Dear Minh Truong,

Even if you buy Xilinx SP601, there may be possibilities that same trouble will occur.
It may not be helpful to solve your problem. And it might not be your best way to handle this.

In such a case, you should try to analyze your data traffic in the physical method with a simple manner.
Measuring your packet by WIRESHARK is one.

Best Regards,

knaruse


投稿日時 2013/10/7 17:06

minhtruong

Dear Knaruse-san,

I already use wireshark to analyze my data trafic, the link below is the screenshot of my computer with wireshark data.

http://www.mediafire.com/view/6lcrvmu27h82u/wireshark#

The problem of TCP_CLOSE_REQ appear with the red color and in the info colum, it has [RST]Seq=1 Win=0 Len=0 and [RST]Seq=1 Win=0 Len=1024

Please help me solve this problem

Sincerely,
Minh Truong


投稿日時 2013/10/8 10:18

knaruse

Dear Minh Truong,

Thank you for sending data,
and we checked your data.

In this event , PC does not disconnect the session(Not issued a FIN).
Therefore, TCP_CLOSE_REQ does not appear.
Explaining this capture as follows:
Until No.718,data transmission was taken place on port number 52750.
This transmission is not ended because there is no FIN.
And then, port number 52751 is trying to open a new session in No.719 ~ No.721.
It won't start because SiTCP can support only one session.
SiTCP can not open a new session without closing a previous session.
At session No.725, SiTCP is sending the data on port number 52750,
but PC is responding with RST in No726.
At this time, probably PC has discarded the session of port number 52750.
SiTCP is responding with RST at No.728 is because at No.727,
default time has not elapsed from disconnecting a previous session in the session of port number 52751.
Normal session has been started since No.731 .
From above, communication is not ended in normal way.
That causes these session not ends with TCP_CLOS_REQ.

Sincerely,
Knaruse


投稿日時 2013/10/9 15:11

minhtruong

Dear Knaruse-san,

I think that my PC already disconnect the session (produce the FIN) as Aokim-san said in the first post.
I upload again my wireshark file and the data which I got from "ss -t -a" command

http://www.mediafire.com/view/i417d9ynis8yatf/ss_command_Oct9_v2.pdf

http://www.mediafire.com/download/7v7y6eiyj7k43ew/Oct_9_v2

I think that my PC produce the FIN but SiTCP does not receive it.

Sincerely,
Minh Truong


投稿日時 2013/10/10 9:45

knaruse

Dear Minh Truong,

Thank you for sending us your data.
Explanation is as follows.

The packet of FIN is not recorded on wireshark.
Please spesify the line No. of the packet of the FIN.
Although it has shifted to the FIN-WAIT-1 state in the TCP dump,
it turns out that the packet of FIN is not sent out.

Sincerely,
Knaruse


投稿日時 2013/10/10 13:55

minhtruong

Dear Knaruse-san,

According to your comments, my PC do not sent out the FIN to SiTCP, so how to send the FIN to SiTCP?

Ussually, I use command: "nc IP_address port_number > data.txt" to take out data, and type Ctrl+C to stop transfer data to my PC.

Best Regards,
Minh Truong


投稿日時 2013/10/17 10:03

k.iwase

Dear Minh Truong,

I think that FIN is not sent to SiTCP because of the state of your PC.
There are possibilities that the FIN is not sent if reception rate is too fast.
Why don't you cut the session after stopping the reception?

Sincerely,
k.iwase


投稿日時 2013/10/21 10:51

minhtruong

Dear Knaruse-san and K.iwase san,

Thanks for your help,
I found the problem in my FADC firmware

I set the value of TCP_RX_WC = 0xffff and this value is not good for SiTCP. So, I change it to TCP_RX_WC = 0x0000 and the issue is solved

Thanks for your help again,

Sincerely,
Minh Truong

This discussion has been closed.