Re: having trouble getting the echo client to work using TCP/uIP on K64F


Paul Sokolovsky
 

Hello Rohit,

On Fri, 26 Aug 2016 11:06:33 +0000
Rohit Grover <Rohit.Grover(a)arm.com> wrote:

Paul,

It is useful to work our way through the core BSD socket API in the
context of Z-uIP.
I'm glad to know you care about this usecase too, and thanks for
sharing this on list, I hope this will be useful feedback for Z's
network stack designers. I also dumped some additional thoughts
on this matter at https://jira.zephyrproject.org/browse/ZEP-741 .


Let's take connect(). Assuming that a net_context has been setup,
connect() can be implemented using the snippet:

net_context_tcp_init(net_context, NULL /* bp */, NET_TCP_TYPE_CLIENT);
while ((status = net_context_get_connection_status(unicast)) != 0) {
fiber_sleep(SOME_SMALL_DURATION);
}

We're passing `bp' as NULL, but it seems un-necessary for
net_context_init() to require a bp. This leads us to commit 61edc68c,
by Jukka, where many of the APIs suddenly acquired an additional 'bp'
parameter. In some cases, this led to code which I'm having trouble
understanding.
Right, I also had a look at that commit. Well, it says it's related to
IPv6 support, and I'm not much familiar with its support in uIP to
assess those changes, but it indeed looks like TCP/IPv4 support might
have regressed as a result. Going to keep looking into that...

, I've attached the diff, but I'll highlight a
snippet. Take the case of tcpip_poll_tcp(), which is responsible for
sending out the initial SYN packet.

@@ -837,12 +837,18 @@ tcpip_poll_udp(struct uip_udp_conn *conn)
/*---------------------------------------------------------------------------*/
#if UIP_TCP
void
-tcpip_poll_tcp(struct uip_conn *conn)
+tcpip_poll_tcp(struct uip_conn *conn, struct net_buf *data_buf)
{
/* We are sending here the initial SYN */
struct net_buf *buf = ip_buf_get_tx(conn->appstate.state);
- uip_set_conn(buf) = conn;
- conn->buf = ip_buf_ref(buf);
+ uip_set_conn(data_buf) = conn;
+
+ /* The conn->buf will be freed after we have established the
connection,
+ * sent the message and received an ack to it. This will happen in
+ * net_core.c:net_send().
+ */
+ conn->buf = ip_buf_ref(data_buf);
+
process_post_synch(&tcpip_process, TCP_POLL, conn, buf);
}

Here we see that we acquire a buf to send out a 'SYN' (refer to
ip_buf_get_tx(...) above), but whereas previously we would associate
it with the new connection and have its ref-count bumped, we now do
those things for the 'data_buf' instead. This is a bit confusing. I
don't see why the handling of the SYN buf needed to be changed.

Rohit.
[]

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

Join devel@lists.zephyrproject.org to automatically receive all group messages.