-
Notifications
You must be signed in to change notification settings - Fork 406
Return error when failing onion packet construction #2271
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
Return error when failing onion packet construction #2271
Conversation
} | ||
|
||
nodes[0].messenger.send_onion_message(&intermediates, Destination::Node(nodes[num_nodes-1].get_node_pk()), test_msg, None).unwrap(); | ||
pass_along_path(&nodes, None); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Draft mode for now as I'm a bit dubious why this pass_along_path
currently fails. I could swear the same test worked before for 17 hops (before rebasing on current main). Also I'm not sure where the discrepancy comes from: while we construct and send the packet with 17 hops just fine, some node on the path receives:
TRACE node 1 [lightning::onion_message::messenger : lightning/src/onion_message/messenger.rs, 407] Forwarding an onion message to peer 02888f2e3df341d21240f769afd83938fdc1878356769aae64141880d810c61dce
TRACE node 2 [lightning::onion_message::messenger : lightning/src/onion_message/messenger.rs, 412] Errored decoding onion message packet: Malformed { err_msg: "HMAC Check failed", err_code: 49157 }
@valentinewallace Do you have any idea where the HMAC failure could come from and how we could catch it before sending?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking into this, will get back this afternoon. I think there’s a bug in pass_along_path where we’ll never assert on the log at the moment :/ not sure if it’s related to the HMAC failure yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@valentinewallace Do you have any idea where the HMAC failure could come from and how we could catch it before sending?
So this was a good catch, I don't think we've ever actually supported sending large OMs (i.e. with >1300-byte hop_data
). Working on a fix :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened #2277
I'm confused how we can panic, since in |
Ah, we would hit a 'subtract with overflow' if the filler length is above the hardcoded 1300 bytes:
As this panic is fixed in #2277, I'll rebase shortly. |
c1296a6
to
005e8d4
Compare
Rebased on #2277. |
Codecov ReportPatch coverage:
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## main #2271 +/- ##
==========================================
+ Coverage 90.92% 91.37% +0.45%
==========================================
Files 104 104
Lines 52757 57580 +4823
Branches 52757 57580 +4823
==========================================
+ Hits 47970 52616 +4646
- Misses 4787 4964 +177
☔ View full report in Codecov by Sentry. |
005e8d4
to
1f0d84f
Compare
Rebased on main after #2077 got merged. |
I agree we should return an error, but we should probably also drop |
Alright, now went ahead and dropped |
f84bbef
to
7168c49
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM after squash
ea0fed4
to
705304e
Compare
Previously, we would panic when failing to construct onion messages in certain circumstances. Here we opt to always rather error out and don't panic if something goes wrong during OM packet construction.
705304e
to
de6649c
Compare
Squashed fixups and included the following changes: index 27e91116..fb2ff3a7 100644
--- a/lightning/src/ln/channelmanager.rs
+++ b/lightning/src/ln/channelmanager.rs
@@ -2730,10 +2730,6 @@ where
let (onion_payloads, htlc_msat, htlc_cltv) = onion_utils::build_onion_payloads(path, total_value, recipient_onion, cur_height, keysend_preimage)?;
- let onion_packet = match onion_utils::construct_onion_packet(onion_payloads, onion_keys, prng_seed, payment_hash) {
- Ok(packet) => packet,
- Err(()) => {
- return Err(APIError::InvalidRoute { err: "Route size too large considering onion data".to_owned()});
- }
- };
+ let onion_packet = onion_utils::construct_onion_packet(onion_payloads, onion_keys, prng_seed, payment_hash)
+ .map_err(|_| APIError::InvalidRoute { err: "Route size too large considering onion data".to_owned()})?;
let err: Result<(), _> = loop { |
Based on #2277.Previously, we could panic when failing to construct onion messages in certain circumstances. Here we opt to always rather error out and don't panic if something goes wrong during OM packet construction.