Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP8266 TCP - connection closure error #4

Closed
wants to merge 1 commit into from
Closed

ESP8266 TCP - connection closure error #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion src/app/esp8266/tcpnew.fth
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -75,6 +75,7 @@ defer respond ( pcb -- close? )
?dup 0= if ( pbuf )
." Connection closed" cr cr
rx-pcb close-connection ( )
ERR_ABRT
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that ERR_OK is appropriate here. This is not a premature abort, but rather a normal shutdown.

That said, looking at the code in lwip/core/tcp_in.c, there is very little difference between the code paths in the two cases. The only difference is that, in the OK case, tcp_output() is called before falling through to the aborted: label. I think that is a good thing, as it permits the stack to proceed apace with the final stages of the connection close dance.

Regarding the timing of tcp_recved versus handle-data, it's unclear to me what is correct. On the one hand, calling tcp_recved early would potentially speed things up by getting the TCP ACK out sooner. On the other hand, it seems prudent to make sure the data is safe before proceeding. On the other other hand, the data is probably safe until the pbuf is freed.

Analysis of tcp_in.c suggests that, before the pbuf is passed to the application, it is disconnected from the pcb, so it should be safe to call tcp_recved before handling the data. That being the case, I have moved the tcp-recved call up to before handle-data. We can keep our fingers crossed.

exit ( -- err )
then ( pbuf )

Expand All @@ -89,8 +90,10 @@ defer respond ( pcb -- close? )
\ Give the data to the application code
handle-data ( pbuf totlen )

\ Release the data buffer
\ Open the window
rx-pcb tcp-recved ( pbuf )

\ Release the data buffer
pbuf-free drop ( )

\ Call the application code to respond to the data
Expand Down