Both when we forget about an opening peer, and at startup. We're
going to be relying on this, and the next patch, as we refactor
peer/channel handling to mirror the db.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This avoids clashing with the new_channel we're about to add to lightningd,
and also matches its counterpart new_initial_channel.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
DEBUG:root:lightningd(16333): 2018-02-08T02:12:21.158Z lightningd(8262): lightning_openingd(0382ce59ebf18be7d84677c2e35f23294b9992ceca95491fcf8a56c6cb2d9de199): Failed hdr decrypt with rn=2
We only hand off the peer if we've not started writing, but that was
insufficient: we increment the sn twice on encrypting packet, so there's
a window before we've actually started writing where this is now
wrong.
The simplest fix is only to hand off from master when we've just written,
and have the read-packet path simply wake the write-packet path.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Combining the two was just awkward, so it's clearer to have separate
functions. And we make the lower-level functions do the escaping.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Currently valgrind developer tests are taking about 25 minutes,
with the non-developer valgrind taking 32.
Split into 6 parts and 2 parts respectively.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
For the impatient! First time users following these steps may get an error like "Unable to locate package libsodium-dev" if apt-get update is not run first.
This caused a bit of confusion for our testers, when funding a channel
the funds are no longer available and listed in `lisfunds`, causing
them to believe funds to have disappeared. This PR adds funds that are
allocated to channels in the `listfunds` output, together with some
info about the channel, to make sure this doesn't happen again.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
The JSON-RPC spec specifies that if the request is unparseable we
should return an error with a NULL id. This is a bit more friendly
than slamming the door in the face.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
As reported by @practicalswift in #945 it is possible to inject
non-printable, or shell escape, characters in a json command, that
will fail to parse and then clear the shell.
Reported-by: @practicalswift
Signed-off-by: Christian Decker <decker.christian@gmail.com>
We get intermittant failure: WIRE_UNKNOWN_NEXT_PEER (First peer not ready)
because CHANNELD_NORMAL and actually telling gossipd that the channel
is available are distinct things: we need both.
(For test_closing_different_fees, we were testing CHANNELD_NORMAL on
the peer, not on l1, too).
But we may also directly send the announcement sigs if the height is
sufficient, so the simplest is to unify the messages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We save wireaddr to databases as a string (which is pretty dumb) but
it turned out that my local node saved '[::ffff:127.0.0.1]:49150'
which our parser can't parse.
Thus I've reworked the parser to make fewer assumptions:
parse_ip_port() is renamed to separate_address_and_port() and is now
far more accepting of different forms, and returns failure only on
grossly malformed strings. Otherwise it overwrites its *port arg only
if there's a port specified. I also made it static.
Then fromwire_wireaddr() hands the resulting address to inet_pton to
figure out if it's actually valid.
Cc: William Casarin <jb55@jb55.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Now we have wirestring, this is much more natural. And with the
24M length limit, we needn't be so concerned about dumping 64k peer
messages in hex.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
A convenient alias for char *, though we don't allow control characters
so our logs can't be fooled with embedded \n.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These are now logically arrays of pointers. This is much more natural,
and gets rid of the horrible utxo array converters.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
