lightningd: re-allow closing negotiation when CLOSINGD_COMPLETE

d822ba1ee accidentally removed this case, which is important: if the
other side didn't get our final matching closing_signed, it will
reconnect and try again.  We consider the channel no longer "active"
and thus ignore it, and get upset when it send the
`channel_reestablish` message.

We could just consider CLOSINGD_COMPLETE to be active, but then we'd
have to wait for the closing transaction to be mined before we'd allow
another connection.

We can't special case it when the peer reconnects, because there
could be (in theory) multiple channels for that peer in CLOSINGD_COMPLETE,
and we don't know which one to reestablish.

So, we need to catch this when they send the reestablish, and hand
that msg to closingd to do negotiation again.  We already have code
to note that we're in CLOSINGD_COMPLETE and thus ignore any result
it gives us.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

lightningd/channel_control.c

@@ -114,7 +114,8 @@ static void peer_start_closingd_after_shutdown(struct channel *channel,
 	}
 
 	/* This sets channel->owner, closes down channeld. */
-	peer_start_closingd(channel, &cs, gossip_index, fds[0], fds[1], false);
+	peer_start_closingd(channel, &cs, gossip_index, fds[0], fds[1],
+			    false, NULL);
 	channel_set_state(channel, CHANNELD_SHUTTING_DOWN, CLOSINGD_SIGEXCHANGE);
 }
 

lightningd/closing_control.c

@@ -121,10 +121,11 @@ static unsigned closing_msg(struct subd *sd, const u8 *msg, const int *fds UNUSE
 }
 
 void peer_start_closingd(struct channel *channel,
-			 struct crypto_state *cs,
+			 const struct crypto_state *cs,
 			 u64 gossip_index,
 			 int peer_fd, int gossip_fd,
-			 bool reconnected)
+			 bool reconnected,
+			 const u8 *channel_reestablish)
 {
 	u8 *initmsg;
 	u64 minfee, startfee, feelimit;
@@ -204,7 +205,8 @@ void peer_start_closingd(struct channel *channel,
 				      channel->next_index[LOCAL],
 				      channel->next_index[REMOTE],
 				      num_revocations,
-				      deprecated_apis);
+				      deprecated_apis,
+				      channel_reestablish);
 
 	/* We don't expect a response: it will give us feedback on
 	 * signatures sent and received, then closing_complete. */

lightningd/closing_control.h

@@ -7,9 +7,10 @@ struct channel_id;
 struct crypto_state;
 
 void peer_start_closingd(struct channel *channel,
-			 struct crypto_state *cs,
+			 const struct crypto_state *cs,
 			 u64 gossip_index,
 			 int peer_fd, int gossip_fd,
-			 bool reconnected);
+			 bool reconnected,
+			 const u8 *channel_reestablish);
 
 #endif /* LIGHTNING_LIGHTNINGD_CLOSING_CONTROL_H */

lightningd/peer_control.c

@@ -502,7 +502,7 @@ void peer_connected(struct lightningd *ld, const u8 *msg,
 			channel->peer->addr = addr;
 			peer_start_closingd(channel, &cs, gossip_index,
 					    peer_fd, gossip_fd,
-					    true);
+					    true, NULL);
 			goto connected;
 		}
 		abort();
@@ -590,6 +590,17 @@ void peer_sent_nongossip(struct lightningd *ld,
 			error = channel->error;
 			goto send_error;
 		}
+
+		/* Reestablish for a now-closed channel?  They might have
+		 * missed final update, so do the closing negotiation dance
+		 * again. */
+		if (fromwire_peektype(in_msg) == WIRE_CHANNEL_REESTABLISH
+		    && channel
+		    && channel->state == CLOSINGD_COMPLETE) {
+			peer_start_closingd(channel, cs, gossip_index,
+					    peer_fd, gossip_fd, true, in_msg);
+			return;
+		}
 	}
 
 	/* Weird request. */