lwIP issue with remote close of persistent TCP connection Topic is solved

If you have a simple question and just want an answer.
Post Reply
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

lwIP issue with remote close of persistent TCP connection

Post by akp »

Hello

I have brought in the lib xtcp 6.0.0 and modified the simple webserver demo into a TCP echo server with persistent connection until closed by peer (basically the same as TCP echo service).

I am using circuit based on MC audio board and also running the AVB/TSN stack with TDM master and RGMII, but with 100Mbps support only (GbE removed) per http://www.xcore.com/viewtopic.php?f=26&t=4731&p=24242

I am testing the echo server by opening a telnet connection from a directly connected Mac that can also receive the AVB data. The issue I am seeing is if I run the lwip stack I am not receiving XTCP_CLOSED event when the peer closes telnet, but I do receive the XTCP_CLOSED event in this circumstance if I run the uIP stack. Any idea why this might be the case?

I understand the lwIP stack is supposed to be higher performance than the uIP stack which might be important at some point in time. It's not a huge issue at present but I haven't tested the throughput of the echo server. I only need about 10kbps right now so I suspect (hope) uIP is capable of that unless someone knows why lwIP is not issuing the XTCP_CLOSED event when the peer closes the connection.

Or is there any compelling reason to use lwIP rather than uIP?


View Solution
jakeh
Posts: 5
Joined: Fri Jul 28, 2017 9:55 am

Post by jakeh »

Hi akp,

I have been able to reproduce your issue. It comes from our lib_xtcp wrapper around LWIP.
We are not correctly handling a LWIP_EVENT_RECV event with a NULL pbuffer.
This should be treated as a disconnect event, and forwarded to the application as a XTCP_CLOSED event.
This will be corrected in a future release.

Until this is fixed, change the code at https://github.com/xmos/lib_xtcp/blob/m ... ip.xc#L576 from

Code: Select all

    
    case LWIP_EVENT_RECV:
      if(p != NULL) {
        enqueue_event_and_notify(pcb->xtcp_conn.client_num, XTCP_RECV_DATA, &(pcb->xtcp_conn), p);
      }
      break;
to

Code: Select all

    
    case LWIP_EVENT_RECV:
      if(p != NULL) {
        enqueue_event_and_notify(pcb->xtcp_conn.client_num, XTCP_RECV_DATA, &(pcb->xtcp_conn), p);
      } else {
        enqueue_event_and_notify(pcb->xtcp_conn.client_num, XTCP_CLOSED, &(pcb->xtcp_conn), NULL);
      }
      break;
This should solve your problem.

Kind Regards,
Jake
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Hi Jake,

Thanks, I will try that out.

By the way, I have updated xtcp_uip and xtcp_lwip to be combinable. Tested ok with xtcp_uip and will be testing with xtcp_lwip... any reason I wouldn't want to run the ip task combinable? Seems an obvious thing to do cooperative multitasking with, especially if you have another IP task like the echo server I mentioned.
User avatar
akp
XCore Expert
Posts: 578
Joined: Thu Nov 26, 2015 11:47 pm

Post by akp »

Hi Jake,

Thank you, that solved the problem. My updates to xtcp_uip and xtcp_lwip to make the combinable seem to work in case xmos is interested in the change. Pretty straightforward, just made new unsafe {} sections inside the while (1) { select { statements (rather than putting the whole while (1) { select { in an unsafe {} section) so it would meet the combinable criterion.

Best,
Adam
Post Reply