-
Notifications
You must be signed in to change notification settings - Fork 96
Regression in v6.6.0 for parsing multi-byte length header that is split across write calls #95
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
Comments
Here are some unit tests that demonstrate the problem (the first for a sanity check for the test approach, then the second revealing the bug). These tests pass on v6.5.0, but the latter test fails with v6.6.0:
|
Introduced in #90 (adding this comment to get it to link to the other bug) |
Would you like to send a Pull Request to address this issue? |
twegener-embertec
added a commit
to embertec-eng/mqtt-packet
that referenced
this issue
Nov 6, 2020
Avoid emitting false errors when not all bytes are present yet when parsing the variable byte integer for the length header. Emit error upon attempting to generate a variable byte integer beyond the maximum allowed size.
Here you go. :-) |
YoDaMa
pushed a commit
that referenced
this issue
Nov 19, 2020
Fix: error handling for Variable Byte Integer #95
@YoDaMa, I think this issue should be closed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The following commit altered parser.js _parseLength such that it generates an error state whenever _parseVarByteNum returns false:
That was to cater for the new max bytes check in _parseVarByteNum, that breaks the case where the remainder of the length header bytes are not available yet (this._list.length <= bytes), since that case is not an error, since it is just waiting for more bytes to be available.
It is relatively rare that it hits this problem, as it only happens if delayed incoming bytes occur at just the right (wrong) time, i.e. when parsing a multi-byte length header field. However, under high traffic we see this occurring a couple times a day since upgrading to mqtt-packet 6.6.0. I have tested winding back to 6.5.0 and we don't hit the problem there.
This is quite serious as when this occurs the byte stream does not get consumed properly, and after the first "Error: Invalid length" error occurs, parsing subsequent incoming bytes gets totally confused and emits numerous errors (losing the data), until the mqtt connection is dropped and re-established.
The text was updated successfully, but these errors were encountered: