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


Jukka Rissanen
 

Hi Rohit and Paul,

On Thu, 2016-09-01 at 03:52 +0300, Paul Sokolovsky wrote:
Hello Rohit,

On Fri, 26 Aug 2016 14:36:07 +0000
Rohit Grover <Rohit.Grover(a)arm.com> wrote:


Paul,

With tcpip_poll_tcp() reverted to its original version:

void
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);

  process_post_synch(&tcpip_process, TCP_POLL, conn, buf);
}

I can now connect and send a packet using the following code run
either as a fiber or a task:
[]


This is already an improvement over the state where I could not
send
using a microkernel. Sending out a second packet before processing
the receipt of the first hasn't worked yet, but I'll leave that
investigation for next week.
Thanks for the above patch, Rohit. So far, that's the most definitive
patch to resolve many different issues. With it and only it I get
pretty working client-side BSD socket API like communication. In
particular, it appears to supersede need for
https://gerrit.zephyrproject.org/r/#/c/4226 - with just a patch
above, I couldn't reproduce overwriting 4 initial data bytes with MSS
option. 

Still, that commit was made in
https://gerrit.zephyrproject.org/r/gitweb?p=zephyr.git;a=commitdiff;h
=61edc68c9ecf221d18acc8037d541f5d79eee3c7 ,
with description 
"net: tcp: Supporting TCP client functionality when using IPv6". I
don't know if something in IPv6 warrants changes to tcpip_poll_tcp()
done in that commit, I guess only Jukka can tell. But the issue in
Unfortunately I do not remember why I changed tcpip_poll_tcp(), the uIP
code (and especially TCP support) is very cryptic and difficult to
follow. One basically needs to run the stack and see how it behaves.


https://gerrit.zephyrproject.org/r/#/c/4226 could be explained by it
pretty well too: comment says "We are sending here the initial SYN",
and allocates a packet to host that SYN (and then other options, like
MSS), but tcpip_poll_tcp() from 61edc68c9 instead of this SYN packet
records actual data packet in some structures where a SYN packet is
expected, so the data packet gets patched with MSS, etc.


Note that I don't get 100% perfect networking with the patch above,
so there may be more issues to tackle (or alternatively, I don't
handle all conditions well in my code). But figuring out if the
tcpip_poll_tcp() should be reverted or not is the most productive
next
step IMHO.




Regards,
Rohit.
Thanks for your hard efforts with the TCP, it is very much appreciated.


Cheers,
Jukka

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