connectd: rescue constant message size feature by exploiting OPT_ONION_MESSAGES (LND)
What the developer wrote
Authored by Rusty Russell
connectd: rescue constant message size feature by exploiting OPT_ONION_MESSAGES (LND)
I 🧡 Laolu!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This change adjusts when Core Lightning pads its network messages to a constant size. Previously padding was controlled by a developer/testing flag. Now it is enabled only when the connected peer advertises support for 'onion messages' (a newer Lightning feature). The commit message says this works around a bug in LND (another Lightning implementation) where LND would disconnect if it received certain padded 'ping' messages. The fix uses onion-message support as a signal that the remote LND version is new enough to tolerate the padding. There is no direct evidence in the diff of a security vulnerability; it reads as a compatibility/interoperability fix that incidentally preserves a privacy feature (uniform packet sizes).
Treat as a compatibility/privacy fix rather than a security patch. Reviewers may want to confirm that the OPT_ONION_MESSAGES feature bit reliably correlates with the LND version that tolerates padded pings, and that falling back to non-uniform writes does not reintroduce traffic-analysis risks for older peers. No urgent security action is indicated by the diff alone.
Security signals we found
Privacy feature preservation: uniform packet sizes can reduce traffic-analysis leakage.
Interoperability workaround: avoids disconnects with LND peers that do not tolerate padded pings.
No direct security bug patched in the diff (no bounds check, auth, crypto, or memory fix).
Commit message references a third-party implementation bug (LND) but does not frame it as a security issue.
Evidence from the diff
In connectd/multiplex.c, use_uniform_writes() now returns true based on feature_offered(peer->their_features, OPT_ONION_MESSAGES) instead of the global peer->daemon->dev_uniform_padding flag. The intent is to keep the ‘uniform padding’ write behavior active only for peers that are known to support onion messages, because the commit author states that older LND versions hang up on the no-reply ping messages used by the padding mechanism, and the upcoming LND v21 both fixes that bug and supports onion messages. The change is a heuristic feature-negotiation gate, not a cryptographic or memory-safety fix.
Changed components
connectd/multiplex.cuse_uniform_writes()peer connection write path / encrypted queue paddingInspect captured patch +5 / −1
diff --git a/connectd/multiplex.c b/connectd/multiplex.c
index 73392ce..48df640 100644
--- a/connectd/multiplex.c
+++ b/connectd/multiplex.c
@@ -481,9 +481,13 @@ static bool have_empty_encrypted_queue(const struct peer *peer)
return membuf_num_elems(&peer->encrypted_peer_out) == 0;
}
+/* Funny story: we discovered an LND bug, where they hung up if we sent
+ * "no reply" ping messages. This was fixed in (the upcoming) v21, which
+ * Laolu pointed out also supports onion messages. Hence we use that
+ * to detect if we should pad packets. */
static bool use_uniform_writes(const struct peer *peer)
{
- return peer->daemon->dev_uniform_padding;
+ return feature_offered(peer->their_features, OPT_ONION_MESSAGES);
}
/* (Continue) writing the encrypted_peer_out array */
Why this scored 34/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.