Amin Bandali writes:
> Have you tried specifying a bootstrap node explicitly with '-b'?
I have now; I'd missed that the system instance's use of
bootstrap.ring.cx stemmed from a configuration file
(/etc/default/dhtnode) that nothing else consulted by default. At this
point, dhtnode -b
Hello,
Aaron M. Ucko writes:
> Petter Reinholdtsen writes:
>
>> I guess someone should test and figure out what the status is. The
>> latest opendht is in Debian unstable and testing now.
>
> As of 2.4.10-1, it no longer floods logs, but it doesn't seem to have
> found anything either:
>
> $
Petter Reinholdtsen writes:
> I guess someone should test and figure out what the status is. The
> latest opendht is in Debian unstable and testing now.
As of 2.4.10-1, it no longer floods logs, but it doesn't seem to have
found anything either:
$ dhtnode
OpenDHT node [...] running on
This issue was closed upstream last year, but it is unclear from the
lack of comments if it was closed because on-one tested it since 2017
or because a fix was commited.
I guess someone should test and figure out what the status is. The
latest opendht is in Debian unstable and testing now.
--
Package: dhtnode
Version: 1.3.4-3
Severity: important
Tags: upstream
dhtnode defaults to connecting to bootstrap.ring.cx, which has both an
IPv4 and an IPv6 address. However, it apparently insists on trying to
connect to the IPv6 address, even from systems like mine that still
lack v6
5 matches
Mail list logo