TCP not receiving conn:on("disconnection",...) following a conn.close()

[eyaleb]

Maybe not a bug.

This looks like a change due to the recent net reimplementation. It is uncommon for my app to reach this code so it took me a while to realise that this logic stopped working.

If this is an intended change, then the doco should probably highlight this. In short, this is a user visible change.

Expected behavior

Issuing a TCP conn:close() triggers a conn:on("disconnection", ....

Actual behavior

disconnection not triggered

Test code

My old code, which worked

conn:on("disconnection", function(conn, data)
	Log ("disconnected")
	do_file ("save")
end)

conn:on("receive", function(conn, data)
	Log ("received '%s'", data)
	conn:close()
end)

but now I need to do

conn:on("disconnection", function(conn, data)
	Log ("disconnected")
	-- does not normally happen
end)

conn:on("receive", function(conn, data)
	Log ("received '%s'", data)
	conn:close()
	do_file ("save")
end)

People who do not bother issuing the close() before a dsleep/restart will not see a problem.

NodeMCU version

Recent dev.

Hardware

Any.

[jmattsson]

Tagging in @djphoenix

[djphoenix]

I don't remember that close method was issued (or not) a callback... But I think current behavior is most correct because callback (for me) means "remote side closed connection". Actually (in code) callback raised when underlying library calls it, and LWIP calls it only when I noted. Not sure about espconn.

[eyaleb]

The important question here is: was this change intended? If so then it is another one for the ChangeLog when merged into master.

I am OK with both behaviours and can see how each can be argued for.

[djphoenix]

This change was become with changing C-level backend from espconn to lwip.
For me, lwip does things right (and not calls disconnection callback when connection closed by local side).
So I agree for note this in ChangeLog.

[marcelstoer]

Added it to milestone notes (transfers to release notes).