gistfile1.txt

Found them.

## LND-side fix

The LND commit that fixes this exact `pong bytes exceeded` disconnect is:

```text
08b26b613745d5e1e63abed15746045d03c8f27a
lnwire+peer: ignore no-reply pings
```

Commit message:

```text
Allow pings in the BOLT 1 no-reply range to decode and be ignored
instead of disconnecting peers. This keeps reconnects compatible with
peers that pad channel_reestablish with no-reply pings.
```

Patch summary:

```diff
diff --git a/lnwire/ping.go b/lnwire/ping.go
@@
-   if p.NumPongBytes > MaxPongBytes {
-       return ErrMaxPongBytesExceeded
-   }
-
+   // Values above MaxPongBytes are still valid on the wire. Per BOLT 1,
+   // receivers must ignore those pings rather than fail deserialization.
    return nil
```

And in `peer/brontide.go`:

```diff
+   // BOLT 1 requires us to ignore pings requesting 65532
+   // or more pong bytes instead of replying or
+   // disconnecting.
+   if msg.NumPongBytes > lnwire.MaxPongBytes {
+       continue
+   }
```

There is a follow-up cleanup commit:

```text
dd61acd9dc8733281c9d76fe100a6c458172ec5f
lnwire: remove stale pong limit error
```

That removes the now-unused error:

```go
ErrMaxPongBytesExceeded = fmt.Errorf("pong bytes exceeded")
```

### Branches containing the LND fix

The fix is already in LND upstream branches:

```text
upstream/master
upstream/v0.21.x-branch
upstream/21-rc-1
```

and some backport branches:

```text
upstream/backport-10763-to-v0.21.x-branch
upstream/backport-10768-to-v0.21.x-branch
```

So the answer on the LND side is:

```text
08b26b613745d5e1e63abed15746045d03c8f27a
```

plus optionally:

```text
dd61acd9dc8733281c9d76fe100a6c458172ec5f
```

## Core Lightning-side mitigation

The CLN commit that mitigates this from the CLN side is:

```text
deddd8e42c9fe8b3f20d4b2967604adaef60f43c
lightningd: `--message-padding` to allow users to disable padding altogether.
```

It adds:

```text
--message-padding=false
```

and documents:

```text
Normally connectd will send extra bytes to peers to make messages
uniform length. Some implementations don't accept these extra bytes:
if we can't detect them, this option sets to false will disable it.
```

Relevant code change in CLN:

```diff
static bool use_uniform_writes(const struct peer *peer)
{
-   return feature_offered(peer->their_features, OPT_ONION_MESSAGES)
+   return peer->daemon->message_padding
+       && feature_offered(peer->their_features, OPT_ONION_MESSAGES)
        && !feature_offered(peer->their_features, 154);
}
```

So for your failing node, the immediate CLN-side workaround/fix is:

```bash
lightningd --message-padding=false
```

or in config:

```text
message-padding=false
```

## The CLN commit that introduced the problematic behavior

This is the one that added padding pings:

```text
8b90d40a7577b157ba1cfe7c8ec1098c9056a87f
connectd: pad messages with dummy pings if needed to make size uniform.
```

It added this:

```c
ping = make_ping(NULL, 65535, pingpad);
```

That is BOLT-valid because `num_pong_bytes >= 65532` means “ignore this ping”, but older/current LND versions before `08b26b613` reject it during decode with:

```text
pong bytes exceeded
```

## Bottom line

Use one of these:

### If you control the LND node

Upgrade/apply:

```text
08b26b613745d5e1e63abed15746045d03c8f27a
lnwire+peer: ignore no-reply pings
```

or run LND from:

```text
v0.21.x-branch
```

or newer once released.

### If you control the CLN node

Disable padding:

```text
message-padding=false
```

using CLN commit:

```text
deddd8e42c9fe8b3f20d4b2967604adaef60f43c
```

or any CLN build that contains it.