connectd: rescue constant message size feature by exploiting option 154 (Eclair).
What the developer wrote
Authored by Rusty Russell
connectd: rescue constant message size feature by exploiting option 154 (Eclair).
I 🧡 tbast!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This commit adjusts when Core Lightning pads ping messages to keep packet sizes uniform. It now skips padding when talking to Eclair nodes that advertise feature bit 154, because Eclair had a similar bug where it did not reply to certain padded pings, which could cause connection problems. The change is a compatibility workaround, not a direct fix for a vulnerability in Core Lightning itself.
Treat as a compatibility/interoperability fix rather than a critical security patch. Monitor for removal of the bit-154 heuristic once Eclair fully phases out that feature bit. No urgent action required for Core Lightning operators, but ensure nodes are updated if they peer with Eclair/Phoenix nodes.
Security signals we found
Workaround for a known interoperability bug in another implementation (Eclair)
Avoids sending 'no reply' pings to peers known to mishandle them
References a prior bug where uniform writes caused issues with non-replying peers
Uses a temporary feature-bit heuristic (bit 154) to identify affected peers
Evidence from the diff
The function use_uniform_writes() previously returned true if the peer advertised OPT_ONION_MESSAGES, meaning Core Lightning would send uniform-sized writes using ‘no reply’ pings. The patch adds an exception: if the peer advertises feature bit 154 (a Phoenix/Eclair custom splices feature bit), use_uniform_writes returns false, so padding pings are not sent. The commit message explains Eclair had the same non-reply bug and also fixed it, so this avoids triggering the buggy behavior in Eclair nodes that still advertise bit 154. This is a protocol-compatibility guard, not a security patch for Core Lightning.
Changed components
connectd/multiplex.cuse_uniform_writes()peer connection padding / uniform write logicInspect captured patch +8 / −1
diff --git a/connectd/multiplex.c b/connectd/multiplex.c
index 48df640..7dbacec 100644
--- a/connectd/multiplex.c
+++ b/connectd/multiplex.c
@@ -485,9 +485,16 @@ static bool have_empty_encrypted_queue(const struct peer *peer)
* "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. */
+
+/* Funnier story: Eclair had the same bug, and have also committed a
+ * fix. They currently use a boutique feature bit 154, which is
+ * "Phoenix-specific custom splices implementation" which Tbast
+ * indicates is being phased out. So if they offer that, don't send
+ * such pings. */
static bool use_uniform_writes(const struct peer *peer)
{
- return feature_offered(peer->their_features, OPT_ONION_MESSAGES);
+ return feature_offered(peer->their_features, OPT_ONION_MESSAGES)
+ && !feature_offered(peer->their_features, 154);
}
/* (Continue) writing the encrypted_peer_out array */
Why this scored 35/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.