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


Rohit Grover
 

Jukka, Paul,

I believe we should go ahead and fix tcpip_poll_tcp() according to the patch I submitted previously.
This fix can supersede https://gerrit.zephyrproject.org/r/#/c/4226, and we can pause on that particular pull request for now. We should also avoid regressing on any IPv6 functionality, so if there are tests we could use to evaluate IPv6 then we should employ them to validate changes to tcpip_poll_tcp().

Fixing tcpip_poll_tcp() isn't the complete answer. With changes to tcpip_poll_tcp(), I can get simple request-response transactions, but sustained/multiple transactions don't work; so there is still reason to suspect that TCP support is unreliable.

The bigger problem appears to be that the uIP port for Z has grown unmaintainable. I can sympathize with Jukka when he says that TCP support on uIP "is very cryptic and difficult to follow."
It is not clear to me if uIP is tricky to port in general, or that Z poses a special challenge.
Does Zephyr intend to switch from uIP to YAIP? If so, then perhaps one strategy would be to wait for YAIP to catch up.
If Zephyr wishes to maintain support for TCP/uIP, then someone needs to take a fresh look at the current uIP port, possibly from the point of view of a porter of uIP.

Regards,
Rohit.

-----Original Message-----
> From: Jukka Rissanen [mailto:jukka.rissanen(a)linux.intel.com]
> Sent: 01 September 2016 09:11
> To: Paul Sokolovsky; Rohit Grover
> Cc: devel(a)lists.zephyrproject.org
> Subject: Re: having trouble getting the echo client to work using TCP/uIP on
> K64F
>
> 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
>
>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

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