blob[] is really a string from the commandline; leave it as a char.
And parsing is much simpler than this code makes it seem!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This surprised me, since the CHANGELOG for [0.8.2] said:
We now announce multiple addresses of the same type, if given. ([3609](https://github.com/ElementsProject/lightning/pull/3609))
But it lied!
Changelog-Fixed: We really do allow providing multiple addresses of the same type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
October was the date Torv2 is no longer supported by the Tor Project;
it will probably not work at all by next release, so we should remove
it now even though it's not quite the 6 months we prefer for
deprecation cycles.
I still see 110 nodes advertizing Torv2 (vs 10,292 Torv3); we still
parse and display it, we just don't advertize or connect to it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Before:
Ten builds, laptop -j5, no ccache:
```
real 0m36.686000-38.956000(38.608+/-0.65)s
user 2m32.864000-42.253000(40.7545+/-2.7)s
sys 0m16.618000-18.316000(17.8531+/-0.48)s
```
Ten builds, laptop -j5, ccache (warm):
```
real 0m8.212000-8.577000(8.39989+/-0.13)s
user 0m12.731000-13.212000(12.9751+/-0.17)s
sys 0m3.697000-3.902000(3.83722+/-0.064)s
```
After:
Ten builds, laptop -j5, no ccache: 8% faster
```
real 0m33.802000-35.773000(35.468+/-0.54)s
user 2m19.073000-27.754000(26.2542+/-2.3)s
sys 0m15.784000-17.173000(16.7165+/-0.37)s
```
Ten builds, laptop -j5, ccache (warm): 1% faster
```
real 0m8.200000-8.485000(8.30138+/-0.097)s
user 0m12.485000-13.100000(12.7344+/-0.19)s
sys 0m3.702000-3.889000(3.78787+/-0.056)s
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tor v2 hidden services have been deprecated for a while:
https://blog.torproject.org/v2-deprecation-timeline .
This prevents user from being able to set them in the configuration
and to connect to them while still letting us be able to parse them
for gossip.
Changelog-Deprecated: lightningd: v2 Tor addresses. Use v3. See https://blog.torproject.org/v2-deprecation-timeline.
Signed-off-by: Antoine Poinsot <darosior@protonmail.com>
We should actually be including this (as it may define _GNU_SOURCE
etc) before any system headers. But where we include <assert.h> we
often didn't, because check-includes would complain that the headers
included it too.
Weaken that check, and include config.h in C files before assert.h.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Didn't generally fixup inside comments and the bech32 code: reformatting that
is just anti-social.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We want to have a static Tor service created from a blob bound to
our node on cmdline
Changelog-added: persistent Tor address support
Changelog-added: allow the Tor inbound service port differ from 9735
Signed-off-by: Saibato <saibato.naga@pm.me>
Add base64 encode/decode to common
We need this to encode the blob for the tor service
Signed-off-by: Saibato <saibato.naga@pm.me>
Thanks clang! Here's the error:
ommon/wireaddr.c:359:14: error: variable 'addr' is used uninitialized whenever
'if' condition is false [-Werror,-Wsometimes-uninitialized]
} else if (addrinfo->ai_family == AF_INET6) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
common/wireaddr.c:364:25: note: uninitialized use occurs here
tal_arr_expand(addrs, addr);
^~~~
./common/utils.h:27:16: note: expanded from macro 'tal_arr_expand'
(*(p))[n] = (s); \
^
common/wireaddr.c:359:10: note: remove the 'if' if its condition is always true
} else if (addrinfo->ai_family == AF_INET6) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
common/wireaddr.c:354:3: note: variable 'addr' is declared here
struct wireaddr addr;
^
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
==12787== Uninitialised byte(s) found during client check request
==12787== at 0x450AAC: memcheck_ (mem.h:247)
==12787== by 0x450B17: towire (towire.c:19)
==12787== by 0x45103D: towire_u8_array (towire.c:159)
==12787== by 0x443235: towire_wireaddr_internal (wireaddr.c:79)
==12787== by 0x46E6F2: towire_connectctl_init (gen_connect_wire.c:229)
==12787== by 0x40D6C8: connectd_init (connect_control.c:369)
==12787== by 0x4186D3: main (lightningd.c:701)
==12787== Address 0x682d8a9 is 361 bytes inside a block of size 568 alloc'd
==12787== at 0x4C2FD5F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12787== by 0x4867A5: tal_resize_ (tal.c:694)
==12787== by 0x41F3EE: opt_add_addr_withtype (options.c:143)
==12787== by 0x41F4D7: opt_add_bind_addr (options.c:155)
==12787== by 0x47E364: parse_one (parse.c:121)
==12787== by 0x47F9C8: opt_parse (opt.c:210)
==12787== by 0x4212F9: handle_opts (options.c:892)
==12787== by 0x41864C: main (lightningd.c:667)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
this enables addr like --addr=autotor:127.0.0.1 or
--addr=autotor:localhost to just use the default tor service port
Signed-off-by: Saibato <Saibato.naga@pm.me>
tal_count() is used where there's a type, even if it's char or u8, and
tal_bytelen() is going to replace tal_len() for clarity: it's only needed
where a pointer is void.
We shim tal_bytelen() for now.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a best effort attempt to skip connection attempts if we detect a broken
ISP resolver. A broken ISP resolver is a resolver that will replace NXDOMAIN
replies with a dummy response. This is best effort in that it'll only detect a
single fixed dummy reply, it'll check only on startup, and will not detect if we
switched networks. It should be good enough for most cases, and in the worst
case it will result in a connection attempt that does not complete.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Reported-by: Glenn Willen <@gwillen>
2018-06-14T01:09:03.495Z lightningd(23766): HSM: created new hsm_secret file
==23785== Syscall param socketcall.bind(my_addr.sin6_flowinfo) points to uninitialised byte(s)
==23785== at 0x5731877: bind (syscall-template.S:78)
==23785== by 0x11767C: make_listen_fd (gossip.c:2405)
==23785== by 0x117DA2: handle_wireaddr_listen (gossip.c:2558)
==23785== by 0x1183B7: setup_listeners (gossip.c:2653)
==23785== by 0x118E86: gossip_activate (gossip.c:2871)
==23785== by 0x11AC42: recv_req (gossip.c:3543)
==23785== by 0x143FF1: next_plan (io.c:59)
==23785== by 0x144AEE: do_plan (io.c:387)
==23785== by 0x144B2C: io_ready (io.c:397)
==23785== by 0x146719: io_loop (poll.c:310)
==23785== by 0x11B0B0: main (gossip.c:3687)
==23785== Address 0x1ffeffffa4 is on thread 1's stack
==23785== in frame #2, created by handle_wireaddr_listen (gossip.c:2539)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Tor wasn't actually working for me to connect to anything, but it worked
for 'ssh -D' testing.
Note that the resulting 'netaddr' is a bit weird, but I guess it's honest.
$ ./cli/lightning-cli connect 021f2cbffc4045ca2d70678ecf8ed75e488290874c9da38074f6d378248337062b
{
"id": "021f2cbffc4045ca2d70678ecf8ed75e488290874c9da38074f6d378248337062b"
}
$ ./cli/lightning-cli listpeers
{
"peers": [
{
"state": "GOSSIPING",
"id": "021f2cbffc4045ca2d70678ecf8ed75e488290874c9da38074f6d378248337062b",
"netaddr": [
"ln1qg0je0lugpzu5ttsv78vlrkhteyg9yy8fjw68qr57mfhsfyrxurzkq522ah.lseed.bitcoinstats.com:9735"
],
"connected": true,
"owner": "lightning_gossipd"
}
]
}
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is useful for the next patch, where we want to hand the unresolved
name through to the proxy.
This also addresses @Saibato's worry that we still called getaddrinfo()
(with the AI_NUMERICHOST option) even if we didn't want a lookup.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means it will effect connect commands too (though it's too
late to stop DNS lookups caused by commandline options).
We also warn that this is one case where we allow forcing through Tor
without a proxy set: it just means all connections will fail.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This takes the Tor service address in the same option, rather than using
a separate one. Gossipd now digests this like any other type.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Risks leakage. We could do lookup via the proxy, but that's a TODO.
There's only one occurance of getaddrinfo (and no gethostbyname), so
we add a flag to the callers.
Note: the use of --always-use-proxy suppresses *all* DNS lookups, even
those from connect commands and the command line.
FIXME: An implicit setting of use_proxy_always is done in gossipd if it
determines that we are announcing nothing but Tor addresses, but that
does *not* suppress 'connect'.
This is fixed in a later patch.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
And use it in wireaddr.
We fix up the double '.onion' in the test case, which seems like an error?
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a rebased and combined patch for Tor support. It is extensively
reworked in the following patches, but the basis remains Saibato's work,
so it seemed fairest to begin with this.
Minor changes:
1. Use --announce-addr instead of --tor-external.
2. I also reverted some whitespace and unrelated changes from the patch.
3. Removed unnecessary ';' after } in functions.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
on all platforms;
because of that BUILD_ASSERT was failing on macOS.
(on macOS "sizeof(sun->sun_path) == 104" and
"sizeof(addr->u.sockname) == 108")
[ Linux man page says it can be as small as 92, so let's use the real value.
I also cleaned up the incorrect comment order on that struct! --RR ]
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we're given a wildcard address, we can't announce it like that: we need
to try to turn it into a real address (using guess_address). Then we
use that address. As a side-effect of this cleanup, we only announce
*any* '--addr' if it's routable.
This fix means that our tests have to force '--announce-addr' because
otherwise localhost isn't routable.
This means that gossipd really controls the addresses now, and breaks
them into two arrays: what we bind to, and what we announce. That is
now what we return to the master for json_getinfo(), which prints them
as 'bindings' and 'addresses' respectively.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
