LWIP_EVENT_ERR may not generate XTCP_ABORTED

[akp]

Hello,

I have my board acting as a TCP server. I am using the XTCP v7.0.0 beta -- which has several improvements in it -- from here: https://github.com/jh14778/lib_xtcp

However, I am seeing an issue where "LWIP_EVENT_ERR: Connection reset." can occur without issuing XTCP_ABORTED event. This occurs in the following situation (ERR_RST occurs before XTCP_SENT_DATA):
- I attempt to send data to peer using i_xtcp.send() and it returns OK
- Peer closes link before I receive XTCP_SENT_DATA Event
- LWIP_EVENT_ERR: Connection reset. events in lwip_tcp_event()
- I don't receive XTCP_SENT_DATA or XTCP_ABORTED

If instead of the above sequence, the ERR_RST occurs after XTCP_SENT_DATA, then I get the following
- I attempt to send data to peer using i_xtcp.send() and it returns OK
- I receive XTCP_SENT_DATA event
- Peer closes link
- LWIP_EVENT_ERR: Connection reset. events in lwip_tcp_event()
- I try to send more data, i_xtcp.send() errors with error -11
- I receive XTCP_ABORTED

Is there a fix for this that can be implemented in the xtcp_lwip.xc code? Perhaps I need to implement a fix when TCP_EVENT_ERR() is called in the underlying LWIP code upon ERR_RST?? There doesn't seem to be any way otherwise to generate an event because lwip executes memp_free(MEMP_TCP_PCB, pcb) so there's no conn we can event?? I apologize for any bad assumptions or general stupidity, my understanding of LWIP and the XTCP code is very minimal.

Obviously to test this issue it helps to have the XMOS chip try to hammer data at the peer. For me I am testing using putty in a raw connection on Win7 x64.

[akp]

I added some code at line 363 of xtcp_lwip/core/tcp_in.c that seems to have fixed the problem. However, I don't know if this is the correct place to do it, presumably it would be better to do it in the XTCP layer, handing the ERR_RST event?

was:

Code: Select all

        TCP_EVENT_ERR(pcb->errf, pcb->callback_arg, ERR_RST);

changed to:

Code: Select all

        TCP_EVENT_RECV(pcb, NULL, ERR_OK, err); /* Hack -- issue TCP_EVENT_RECV with NULL so the xtcp_lwip.xc can issue XTCP_CLOSED */
        TCP_EVENT_ERR(pcb->errf, pcb->callback_arg, ERR_RST);

[ozel]

Are there any news regarding lib_XTCP updates? jakeh, peter?
I ran into the same issue like akp. But applying his suggestion leads sometimes to crashes due to illegal memory access.
Since I handle my high-bandwith outbound traffic via UDP now outside of XTCP, using the the high-priority MAC channels, I could go back to older XTCP versions, even UIP.
I'm currently using the gigabit RGMII mac only configured for 100 Mbit (as described on the forums).
It would be good to know how the future of lib_XTCP looks like. I like the newer API of the v7 Beta quite a bit, it just seems not ready for production, yet.
The last update of the official library (v6) is now one year old.

Besides the connection problem above, I'm observing regular TCP retransmissions followed by ARP requests because XTCP is sometimes not responding for seconds...
As far as I can see it's not due to my code...
It would be nice if we could be able to compare LWIP with UIP. Is there at all a way to use UIP with a gigabit phy?
It seems link related up/down notification is handled very differently between 100 Mbit MAC/UIP and Gigabit MAC/LWIP.