fix(server): treat a client disconnect as a normal end, not an error - #847
Open
Poseidonas wants to merge 1 commit into
Open
fix(server): treat a client disconnect as a normal end, not an error#847Poseidonas wants to merge 1 commit into
Poseidonas wants to merge 1 commit into
Conversation
Client.disconnect() sends a COTP Disconnect Request, which receive_data()
rejected as an unexpected PDU, so an ordinary goodbye from the library's
own client was logged as
ERROR Error handling client ('127.0.0.1', 58143): Expected COTP DT, got 0x80
COTP_DR and COTP_DC were already defined but never used on the receiving
side. A DR is now confirmed with a DC and ends the connection through the
path _handle_client already treats as a normal disconnect. Sending the
confirmation is best effort, since a client that closes right after the
request may already be gone.
A peer that goes away before the ISO handshake completes was logged the
same way; that is routine (port scans, health checks, a cancelled connect)
and is now reported at info level.
Measured against the library's own client and a raw socket: a clean
disconnect after a request, a clean disconnect without one, a plain TCP
close and an abrupt reset all logged an error before, and none do now.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #846.
Client.disconnect()sends a COTP Disconnect Request, whichreceive_data()rejected as an unexpected PDU, so an ordinary goodbye from the library's own client was logged as an error:COTP_DRandCOTP_DCwere already defined inServerISOConnectionbut never used on the receiving side. A DR is now confirmed with a DC and ends the connection through the path_handle_client()already treats as a normal disconnect. Sending the confirmation is best effort — a client that closes right after the request may already be gone, which is what the library's own client does.accept_connection()logged a peer that leaves before the handshake completes the same way; that is routine, so it is reported at info level now.Measured, before and after, on the four ways a client can leave — a clean disconnect after a request, a clean disconnect without one, a plain TCP close and an abrupt reset. All four logged an error before; none do now, and the normal disconnect reads:
Three tests cover it: the DC framing, that a DR ends the connection and is confirmed, and that it still ends cleanly when the confirmation cannot be sent. Each fails without the change.
pytestis 1774 passed, andmypyandruffreport the same counts as master.One thing I did not touch:
snap7/connection.pyandsnap7/async_client.pyhave the sameExpected COTP DTcheck on the client side, so a device that sends a DR would be reported as an error there too. I have no hardware to see whether a real CPU does that, so I left it alone rather than guess.