funding_locked sent before channel_reestablish

[TheBlueMatt]

This may be an old bug, I saw it while testing against the testnet.yalls.org node:

INFO  [lightning::ln::peer_handler : /home/matt/.cargo/git/checkouts/rust-lightning-61cf011b3b289b3b/7d6b98f/lightning/src/ln/peer_handler.rs, 629] Received peer Init message: data_loss_protect: supported, initial_routing_sync: not requested, upfront_shutdown_script: supported, unkown local flags: present, unknown global flags: present
...
TRACE [lightning::ln::peer_handler : /home/matt/.cargo/git/checkouts/rust-lightning-61cf011b3b289b3b/7d6b98f/lightning/src/ln/peer_handler.rs, 605] Received message of type 36 from 027455aef8453d92f4706b560b61527cc217ddf14da41770e8ed6607190a1851b8
TRACE [lightning::ln::channelmanager : /home/matt/.cargo/git/checkouts/rust-lightning-61cf011b3b289b3b/7d6b98f/lightning/src/ln/channelmanager.rs, 2225] Closing channel 51eb6695576cac1e3fb3a829b6b93e86f61d121dc59a5952da048138df33a34a due to Close-required error: Peer sent funding_locked when we needed a channel_reestablish
...
TRACE [lightning::ln::peer_handler : /home/matt/.cargo/git/checkouts/rust-lightning-61cf011b3b289b3b/7d6b98f/lightning/src/ln/peer_handler.rs, 605] Received message of type 136 from 027455aef8453d92f4706b560b61527cc217ddf14da41770e8ed6607190a1851b8

While the spec doesn't call it out explicitly, its somewhat nonsensical to send the funding_locked before the channel_reestablish:

if next_commitment_number is 1 in both the channel_reestablish it sent and received:
    MUST retransmit funding_locked.
otherwise:
    MUST NOT retransmit funding_locked.

as the first text there refers to the channel_reestablish in the past tense, and, really, why would you send a message about a channel before reestablishing the channel.

[halseth]

Related: #2555

[devrandom]

Just ran into this too

[TheBlueMatt]

I'm not sure how we can work around this, either? It seems lnd sometimes simply never sends a channel_reestablish and we could guess it based on the fact that we aren't locked yet, but that's not guaranteed as we could be locked and simply have had it happen while we were offline.

[Overtorment]

just had this issue. any plans to fix it?

[Roasbeef]

It seems lnd sometimes simply never sends a channel_reestablish and we could guess it based on the fact that we aren't locked yet,

So you mean upon reconnection you never see a chan reest message sent? It's the very first thing that happens once a "link" is created, if this isn't the "initial" funding event: https://github.com/lightningnetwork/lnd/blob/master/htlcswitch/link.go#L673

just had this issue. any plans to fix it?

How's the issue manifesting in your specific context?

[TheBlueMatt]

Upon reconnection, more often than not, the first thing lnd does is send a funding_locked prior to the channel_reestablish message (which is required to come first, as lnd is required to check the values in it before deciding whether or not to send a funding_locked at all). C-lightning has special code to work around this case (by storing the funding_locked in memory until a channel_reestablish appears), but we do not currently have any such workaround, so we just force-close and kill the connection.

[TheBlueMatt]

To complete the reference list, the c-lightning workaround was merged at ElementsProject/lightning#2373

[Crypt-iQ]

This is because the stateStep function in funding/manager.go will call sendFundingLocked before the link has time to send ChannelReestablish

[Crypt-iQ]

I think lnd doesn't send channel reestablish if the channel is pending (hasn't hit min confs yet)

[TheBlueMatt]

I don't think that's, itself, a major issue, but you need to send it before you send the channel_ready.