Strip the type and length prefix from the custommsg hook call #4394
Conversation
This file contains 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
cdecker
force-pushed
the
custommsg-raw
branch
from
e5c2aef
to
066a116
Compare
rustyrussell
requested changes
Feb 24, 2021
cdecker
force-pushed
the
custommsg-raw
branch
2 times, most recently
from
8c5553d
to
276564c
Compare
We were always prefixing the `message` field with the internal type prefix 0x0407, followed by the length prefix. Neither is needed since the type being constant is of no interest to the plugin and the length being implicit due to the JSON-encoding. Reported-by: Ilya Evdokimov Changelog-Fixed: plugin: The `custommsg` hook no longer includes the internal type prefix and length prefix in its `payload` Changelog-Deprecated: plugin: The `message` field on the `custommsg` hook is deprecated in favor of the `payload` field, which skips the internal prefix.
|
Removed the |
|
Ack 96e9d79 |
cdecker
added a commit
to cdecker/lightning
that referenced
this pull request
Mar 5, 2021
Looks like ElementsProject#4394 treated a symptom but not the root cause. We were actually sending the message framed with the WIRE_CUSTOMMSG_OUT and the length prefix over the encrypted connection to the peer. It just happened to be a valid custommsg... This fixes the issue, and this time I made sure we actually send the raw message over the wire. However for backward compatibility we needed to imitate the faulty behavior which is 90% of this patch :-) Changelog-Fixed: plugin: `dev-sendcustommsg` included the type and length prefix when sending a message.
rustyrussell
pushed a commit
that referenced
this pull request
Mar 9, 2021
Looks like #4394 treated a symptom but not the root cause. We were actually sending the message framed with the WIRE_CUSTOMMSG_OUT and the length prefix over the encrypted connection to the peer. It just happened to be a valid custommsg... This fixes the issue, and this time I made sure we actually send the raw message over the wire. However for backward compatibility we needed to imitate the faulty behavior which is 90% of this patch :-) Changelog-Fixed: plugin: `dev-sendcustommsg` included the type and length prefix when sending a message.
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.
We were always prefixing the
messagefield with the internal typeprefix 0x0407, followed by the length prefix. Neither is needed since
the type being constant is of no interest to the plugin and the length
being implicit due to the JSON-encoding.
Reported-by: Ilya Evdokimov