connectd: fix diagnostics if we get a long delay.
What the developer wrote
Authored by Rusty Russell
connectd: fix diagnostics if we get a long delay.
In a0fd72eb5e0 I added a diagnostic message if messages cause large
delays, *but* I didn't set the "peer_in_lasttime" variable in the case
of locally-handled packets.
I really want this in the release: the point of this was to try to
diagnose some high-latency ping issues we've seen on the real network.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
What changed, and why it matters
This is a small bugfix inside Core Lightning's connection handling code. It corrects a diagnostic timer so that latency measurements blame the right network message. The commit itself is not a security fix and does not appear exploitable; it is described by the author as a debugging aid for real-world ping latency issues.
Treat as a normal bugfix. No security response is indicated by the commit content or message. If the project is tracking the underlying high-latency ping issue, ensure the corrected diagnostics are included in the release as the author requests.
Security signals we found
No security-relevant signal in the diff or commit message
Change is framed by the author as a diagnostic/latency-measurement fix
No input validation, cryptographic, authorization, or memory-management changes
Evidence from the diff
The patch updates connectd/multiplex.c so that peer->peer_in_lasttime is set consistently. Previously, when a decrypted peer message was handled locally (handle_message_locally returned true), the code returned early via next_read without recording the timestamp, so the ‘long delay’ diagnostic introduced in a0fd72eb5e0 would attribute latency to the wrong message. The fix also adds an io_wake(&peer->peer_in) in write_to_peer when the outgoing queue is empty, ensuring the read side is notified. These are correctness/diagnostic changes, not memory-safety or authorization fixes.
Changed components
connectd/multiplex.cpeer message read/write looplatency diagnostic loggingInspect captured patch +7 / −2
diff --git a/connectd/multiplex.c b/connectd/multiplex.c
index 8740905b..d7cbf80e 100644
--- a/connectd/multiplex.c
+++ b/connectd/multiplex.c
@@ -1093,6 +1093,7 @@ static struct io_plan *write_to_peer(struct io_conn *peer_conn,
if (!msg) {
/* Tell them to read again, */
io_wake(&peer->subds);
+ io_wake(&peer->peer_in);
/* Wait for them to wake us */
return msg_queue_wait(peer_conn, peer->peer_outq,
@@ -1266,8 +1267,11 @@ static struct io_plan *read_body_from_peer_done(struct io_conn *peer_conn,
return next_read(peer_conn, peer);
/* If we swallow this, just try again. */
- if (handle_message_locally(peer, decrypted))
- return next_read(peer_conn, peer);
+ if (handle_message_locally(peer, decrypted)) {
+ /* Make sure to update peer->peer_in_lastmsg so we blame correct msg! */
+ io_wake(peer->peer_outq);
+ goto out;
+ }
/* After this we should be able to match to subd by channel_id */
if (!extract_channel_id(decrypted, &channel_id)) {
@@ -1334,6 +1338,7 @@ static struct io_plan *read_body_from_peer_done(struct io_conn *peer_conn,
/* Wait for them to wake us */
peer->peer_in_lastmsg = type;
+out:
peer->peer_in_lasttime = time_mono();
return io_wait(peer_conn, &peer->peer_in, next_read, peer);
Why this scored 14/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.