TCP/client-mode: disconnect #2065

zephyrbot · 2016-07-04T18:42:46Z

Reported by Flavio Santes:

In order to close a connection with a server, the client must:

set the UPI_CLOSE flag
send something to the server

This should be seen as a design failure, because some high-level protocols consider unwanted data as errors.

Furthermore, the high-level network API must provide a mechanism to close a connection in an easy way.

(Imported from Jira ZEP-522)

zephyrbot · 2016-07-12T00:26:19Z

by Sharron LIU:

Andrei, can you update status on this? It's highest priority issue.

zephyrbot · 2016-07-25T12:43:44Z

by Ravi kumar Veeramally:

Exchanged information thru mail from Flavio.

The reported issue refers to the IP stack ignoring the CLOSE flag. So, if a patch is submitted such that the CLOSE flag is processed by the stack, I am sure that everything will be fine.

Furthermore, the GH-2065 is also related to the way the stack is implemented. It does not make sense that if a Zephyr app wants to connect or disconnect it must send "something", I mean, a payload. So, IMHO that behaviour must be avoided, because it is based on a very limited use-case that blocks our work.

zephyrbot · 2016-08-03T11:37:10Z

by Ravi kumar Veeramally:

tcp-conn-close.pcapng (size: 12700)

zephyrbot · 2016-08-03T11:39:19Z

by Ravi kumar Veeramally:

tcp-bug.patch (size: 3138)

zephyrbot · 2016-08-03T11:46:29Z

by Ravi kumar Veeramally:

Hi Flavio,

Please find attached wireshark [^tcp-conn-close.pcapng] log, and also changes in echo_server application. [^tcp-bug.patch] .

We have net tools in https://gerrit.zephyrproject.org/r/#/admin/projects/net-tools.

I tried echo-server running in qemu and echo-client on linux host. Attached sample tcp log from wireshark. It shows that core stack handles close connection properly.

Please try this.
Patch which I attached is only changes in sample test, nothing in core stack.

Apply the patch.
goto net tools and run ./loop-socat.sh
and sudo ./loop-slip.sh
run echo-server with 'make qemu'
run echo-client from net tools
sudo ./echo-client 2001:db8::2 -t

Let me know your findings.

zephyrbot · 2016-08-03T16:18:27Z

by Flavio Santes:

Before to do any test from my side, I kindly ask you to test this patch in real hardware (Galileo). Once you verify your solution we can close this.

zephyrbot · 2016-08-03T16:35:22Z

by Flavio Santes:

Could you submit your solution in Gerrit?

zephyrbot · 2016-08-03T16:43:51Z

by Flavio Santes:

Last comment, could you run your tests in IPv4?

zephyrbot · 2016-08-04T07:28:21Z

by Ravi kumar Veeramally:

Ok, I will try with Galileo and IPv4.

zephyrbot · 2016-08-04T12:26:51Z

by Ravi kumar Veeramally:

tcp-conn-close-ipv4.pcapng (size: 11048)

zephyrbot · 2016-08-04T12:27:27Z

by Ravi kumar Veeramally:

Attached Ipv4 pcap log [^tcp-conn-close-ipv4.pcapng] . I haven't verified on Galileo, I will try that next.

zephyrbot · 2016-08-04T13:57:11Z

by Ravi kumar Veeramally:

tcp-conn-close-ipv4-galileo.pcapng (size: 34712)

zephyrbot · 2016-08-04T13:57:14Z

by Ravi kumar Veeramally:

Attached Galileo log. [^tcp-conn-close-ipv4-galileo.pcapng]

zephyrbot · 2016-08-06T21:01:55Z

by Flavio Santes:

Ravi kumar Veeramally I appreciate your help, but if you have a patch for this issue please submit it trough Gerrit.

zephyrbot · 2016-08-08T08:58:40Z

by Ravi kumar Veeramally:

Flavio, I don't have any core IP stack related patch. Patch which I attached here is few changes in application to test different environments( like, based on network switch subnet defining src IP address according to it.). But anyway I will send attached patch to gerrit.

zephyrbot · 2016-08-08T09:54:31Z

by Ravi kumar Veeramally:

https://gerrit.zephyrproject.org/r/#/c/3935/
https://gerrit.zephyrproject.org/r/#/c/3936/

Submitted patches related to sample changes, this will help to run samples properly. No changes in core IP stack.

zephyrbot · 2016-08-10T00:16:36Z

by Flavio Santes:

Hello Ravi, please document your findings, the ones you comment in gerrit. This is important for all the engineers developing network applications.

Even so, I do not see how this will fix the current issue (if any). Could you please share with me the line of code that handles the disconnect in client mode? If there is no mechanism for that task, please specify it.

Regards

zephyrbot · 2016-08-10T07:08:37Z

by Ravi kumar Veeramally:

As per the bug description core IP stack doesn't handle TCP disconnect. I tried with possible different scenarios TCP/IPv6|IPv4 between qemu and in Galileo. I provided the pcap logs. Connect, data exchange and disconnect seems fine in all scenarios.

Patches are not related to this issue at all, samples in zephyr/sample/net are provided for few scenarios. When I tried to check TCP in IPv6 and IPv4 in qemu and galileo, I noticed that it requires few changes in samples. That's it.

https://gerrit.zephyrproject.org/r/#/c/3935/ is about proper usage of NET_TESTING_USE_RFC3849_ADDRESSES define and https://gerrit.zephyrproject.org/r/#/c/3936 is about Rx buffers (depends on network environment, we have to allocate minimum number of Rx/tx buffers).
That is the reason I didn't specify Jira id in git commit.

So if you find some issue, please provide samples, logs and steps to reproduce the scenario. I tried possible scenarios based on "Core stack doesn't handle TCP disconnect".

zephyrbot · 2016-08-10T12:00:31Z

by Flavio Santes:

The original description and the extended one that I sent to you describe something not yet solved.

If you have sample code that handles this situation with the high-level API please share it. Otherwise, if this functionality is handled internally by the current API, please specify that.

zephyrbot · 2016-08-10T12:12:47Z

by Ravi kumar Veeramally:

Can you provide your samples or test and logs where the issue is. Steps to reproduce the issue.

zephyrbot · 2016-08-10T14:20:05Z

by Flavio Santes:

The sample code I am using can be found at: samples/net/echo_client and echo_server.

You say there is no issue, so I must assume, everything is fine, right?.

However, do you know how to handle this situation with the high-level API?. Where is the sample code that shows how you, the maintainers, use the API?

As you may be aware, 1.5 and perhaps 1.6 will use the "old IP stack", so I am not the only one interested in sample code that works.

Regards.

zephyrbot · 2016-08-11T07:20:40Z

by Ravi kumar Veeramally:

Looks like my message is not clear. I didn't say there is no issue. I said, I tried few possibilities which I could. In those trials I didn't see the issue which you described. So I am asking you to provide scenario and steps, if possible logs will be helpful.

And the rest "high-level API and sample code using API", I don't understand your concern (how does core stack doesn't handle close flag related to High-level API).

zephyrbot · 2016-08-11T17:21:24Z

by Flavio Santes:

I apologize if I was not clear enough. Given your feedback and after discussing this issue with my team. I think it is better to keep this issue closed. I will open other Jiras trying to only focus on one issue:

Number of RX/TX buffers is hardware dependent
See comments at https://gerrit.zephyrproject.org/r/#/c/3936/
Looping connect and disconnect for TCP client mode applications
This new Jira only focuses on MQTT fail to re-connect to the broker. #2157 (see MQTT fail to re-connect to the broker. #2157's sample code)
MQTT fail to re-connect to the broker. #2157 is seen as a consequence of the issue we are discussing
here (tcp disconnect issue)

What do you think?

zephyrbot · 2016-08-15T07:20:24Z

by Ravi kumar Veeramally:

ok.

I will try/investigate 632 and let you know.

zephyrbot · 2016-08-16T02:25:13Z

by Sharron LIU:

Please reporter verify this.

zephyrbot · 2016-08-16T02:39:11Z

by Flavio Santes:

We are still working on this. So far, it could not be verified at all.

zephyrbot · 2016-08-16T07:15:23Z

by Mark Linkmeyer:

Flavio Santes , if this isn't fixed correctly, I think it's appropriate to move it to the Reopened state and then back into the Accepted state so it's in Dev's queue to be fixed.
Ravi kumar Veeramally

zephyrbot · 2016-08-16T07:36:45Z

by Ravi kumar Veeramally:

As per the bug description stack doesn't handle disconnect/close flag. I have tried with few scenarios where client application connects and disconnects. Provided pcap logs. It seems fine.

But actual bug is GH-2157, where MQTT client connect and disconnect and in a loop its trying to connect/disconnect again. Looks like some issue in reconnection as per its description. I am investigating it. Asked bit more details in GH-2157.

zephyrbot · 2016-08-16T13:35:22Z

by Ravi kumar Veeramally:

Flavio, Finally I could reproduce the GH-2157 issue. Looks like this bug doesn't have enough information to reproduce GH-2157 scenario and seems duplicate of it. So I recommend mark this one as duplicate to GH-2157 and let's figure it out. What do you say?

Please check my comments in GH-2157.

zephyrbot · 2016-08-17T02:34:40Z

by Flavio Santes:

Ravi kumar Veeramally : sounds good to me.

zephyrbot · 2016-08-18T17:55:46Z

by Kuo-Lang Tseng:

Based on comments from Ravi kumar Veeramally and Flavio Santes , closing this as duplicate of GH-2157.

zephyrbot · 2016-08-18T17:55:46Z

Blocks GH-1970

zephyrbot · 2016-08-18T17:55:46Z

Blocks GH-1969

zephyrbot · 2016-08-18T17:55:46Z

Blocks GH-2015

zephyrbot · 2016-08-18T17:55:46Z

Blocks GH-2157

zephyrbot closed this as completed Aug 8, 2016

zephyrbot added priority: high High impact/importance bug area: Networking bug The issue is a bug, or the PR is fixing a bug labels Sep 23, 2017

zephyrbot added this to the v1.5.0 milestone Sep 23, 2017

zephyrbot assigned rveerama1 Sep 23, 2017

This was referenced Sep 23, 2017

MQTT fail to re-connect to the broker. #2157

Closed

Network TCP API is adhoc and makes arbitrary assumptions #2256

Closed

TCP/client-mode: disconnect #2065

TCP/client-mode: disconnect #2065

Comments

zephyrbot commented Jul 4, 2016 • edited Loading

zephyrbot commented Jul 12, 2016

zephyrbot commented Jul 25, 2016 • edited Loading

zephyrbot commented Aug 3, 2016 • edited Loading

zephyrbot commented Aug 3, 2016 • edited Loading

zephyrbot commented Aug 3, 2016

zephyrbot commented Aug 3, 2016

zephyrbot commented Aug 3, 2016

zephyrbot commented Aug 3, 2016

zephyrbot commented Aug 4, 2016

zephyrbot commented Aug 4, 2016 • edited Loading

zephyrbot commented Aug 4, 2016

zephyrbot commented Aug 4, 2016 • edited Loading

zephyrbot commented Aug 4, 2016

zephyrbot commented Aug 6, 2016

zephyrbot commented Aug 8, 2016

zephyrbot commented Aug 8, 2016

zephyrbot commented Aug 10, 2016

zephyrbot commented Aug 10, 2016

zephyrbot commented Aug 10, 2016

zephyrbot commented Aug 10, 2016

zephyrbot commented Aug 10, 2016

zephyrbot commented Aug 11, 2016

zephyrbot commented Aug 11, 2016 • edited Loading

zephyrbot commented Aug 15, 2016

zephyrbot commented Aug 16, 2016

zephyrbot commented Aug 16, 2016

zephyrbot commented Aug 16, 2016

zephyrbot commented Aug 16, 2016 • edited Loading

zephyrbot commented Aug 16, 2016 • edited Loading

zephyrbot commented Aug 17, 2016

zephyrbot commented Aug 18, 2016 • edited Loading

zephyrbot commented Aug 18, 2016 • edited Loading

zephyrbot commented Aug 18, 2016 • edited Loading

zephyrbot commented Aug 18, 2016 • edited Loading

zephyrbot commented Aug 18, 2016 • edited Loading

zephyrbot commented Jul 4, 2016 •

edited

Loading

zephyrbot commented Jul 25, 2016 •

edited

Loading

zephyrbot commented Aug 3, 2016 •

edited

Loading

zephyrbot commented Aug 3, 2016 •

edited

Loading

zephyrbot commented Aug 4, 2016 •

edited

Loading

zephyrbot commented Aug 4, 2016 •

edited

Loading

zephyrbot commented Aug 11, 2016 •

edited

Loading

zephyrbot commented Aug 16, 2016 •

edited

Loading

zephyrbot commented Aug 16, 2016 •

edited

Loading

zephyrbot commented Aug 18, 2016 •

edited

Loading

zephyrbot commented Aug 18, 2016 •

edited

Loading

zephyrbot commented Aug 18, 2016 •

edited

Loading

zephyrbot commented Aug 18, 2016 •

edited

Loading

zephyrbot commented Aug 18, 2016 •

edited

Loading