-
Notifications
You must be signed in to change notification settings - Fork 992
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.
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
msg deserialization error causes peer thread to loop continuously #2793
Comments
cc @hashmap |
False alarm. Lines 47 to 64 in b9db129
|
This stuff is really confusing - we put an error on the error channel in the above case (the connection close logic is asynchronous). This is then picked up in But the logic here does subtly different things for a serialization error vs. any other kind of error - Lines 416 to 463 in b9db129
Specifically - we will close a connection for a serialization error unless the peer is
i.e. We will unban a currently
|
This is resolved now I think (went down various related rabbit holes). |
We fail to deserialize a p2p msg if the
msg_len
exceeds a definedmax_len
(per msg type).If this happens we have read the 11 bytes of the msg header off the stream but we have not read the msg body itself.
We require every msg to begin with a pair of "magic bytes" that indicate the start of a msg header.
If the next bytes are not the magic bytes then we are going to read chunks of 11 bytes at a time and if we are misaligned by even one byte we will not identify the next msg header correctly.
In fact this is not limited to the
msg_len
check. Any error occurring during deserialization of the msg header or the msg itself will cause this.Is my understanding here correct?
max_len
is treated as a serialization errorA couple of alternative approaches -
Related #2791.
The text was updated successfully, but these errors were encountered: