Open whit2333 opened 9 years ago
Very similar result, but ending at:
bittorrent-dht [7e30e20] terminating lookup (get_peers) ef27491bdebe1026b1be58c295c8d1c9fe5f99c1 +1ms
bittorrent-dht [7e30e20] K closest nodes are: +0ms
bittorrent-dht [7e30e20] 192.34.86.36:6881 9130b8ef1c30ef269b014f3f0229123154673bcc +0ms
bittorrent-dht [7e30e20] 104.236.212.110:6881 5bd26e8f70cab61951fe22e0c2c419ebc175f153 +0ms
bittorrent-dht [7e30e20] addNode 76076dcf73c94815e3760d01a548cf1388a0e267 82.45.235.43:56384 discovered from 82.45.235.43:56384 +739ms
bittorrent-dht [7e30e20] got find_node 76076dcf73c94815e3760d01a548cf1388a0e267 from 82.45.235.43:56384 +1ms
No more messages afterwards.
npm 2.10.0 nodejs 0.12.3 git 2.4.1 gittorrent 0.1.5
Clone hangs here too. Gist at https://gist.github.com/philip-wernersbach/24e1f3bab529271240be. I let it run for about five minutes after it hung before I killed it.
OS X Yosemite nodejs 0.12.2 git 2.4.0 gittorrent 0.1.7
@philip-wernersbach What are you trying to clone? I think the problem for you might just be that the thing you're cloning isn't being seeded, and #5 isn't done yet for a fallback.
I'm trying to clone this repository.
@philip-wernersbach Could you try again, and let me know what hash you see for "Okay, we need to get: .."? I think the problem is that I just pushed out an update without also seeding it.
It's getting ec9f63e828de47aeb15c28b7a4ebacee71770276. I just tried and was able to download it, so the problem was seeding.
It's getting a connection now, but still hangs: The tail of the output is
bittorrent-swarm:peer new Peer 10.20.30.3:30000 +999ms
bittorrent-swarm _drain numConns 1 maxConns 55 +0ms
bittorrent-swarm drain (1 queued, 0/55 peers) +1ms
bittorrent-swarm tcp connect attempt to 10.20.30.3:30000 +0ms
bittorrent-swarm drain (1 queued, 0/55 peers) +15s
bittorrent-swarm tcp connect attempt to 127.0.0.1:38677 +1ms
bittorrent-swarm drain (0 queued, 0/55 peers) +1ms
bittorrent-swarm:peer destroy Peer 10.20.30.3:30000 (error: connect timeout) +25s
bittorrent-swarm _drain numConns 1 maxConns 55 +0ms
bittorrent-swarm drain (0 queued, 0/55 peers) +0ms
bittorrent-swarm conn 10.20.30.3:30000 closed: will re-add to queue in 5000ms (attempt 2) +0ms
bittorrent-swarm:peer new Peer 10.20.30.3:30000 +5s
bittorrent-swarm _drain numConns 1 maxConns 55 +0ms
bittorrent-swarm drain (1 queued, 0/55 peers) +0ms
bittorrent-swarm tcp connect attempt to 10.20.30.3:30000 +1ms
bittorrent-swarm drain (1 queued, 0/55 peers) +30s
bittorrent-swarm tcp connect attempt to 127.0.0.1:38677 +0ms
bittorrent-swarm drain (0 queued, 0/55 peers) +1ms
bittorrent-swarm:peer destroy Peer 10.20.30.3:30000 (error: connect timeout) +25s
bittorrent-swarm _drain numConns 1 maxConns 55 +0ms
bittorrent-swarm drain (0 queued, 0/55 peers) +0ms
bittorrent-swarm conn 10.20.30.3:30000 closed: will re-add to queue in 15000ms (attempt 3) +1ms
bittorrent-swarm:peer new Peer 10.20.30.3:30000 +15s
bittorrent-swarm _drain numConns 1 maxConns 55 +0ms
bittorrent-swarm drain (1 queued, 0/55 peers) +0ms
bittorrent-swarm tcp connect attempt to 10.20.30.3:30000 +0ms
bittorrent-swarm:peer destroy Peer 10.20.30.3:30000 (error: connect timeout) +25s
bittorrent-swarm _drain numConns 1 maxConns 55 +0ms
bittorrent-swarm drain (0 queued, 0/55 peers) +0ms
bittorrent-swarm conn 10.20.30.3:30000 closed: will not re-add (max 3 attempts) +0ms
bittorrent-swarm drain (1 queued, 0/55 peers) +1m
bittorrent-swarm tcp connect attempt to 127.0.0.1:38677 +0ms
bittorrent-swarm drain (0 queued, 0/55 peers) +0ms
bittorrent-swarm drain (1 queued, 0/55 peers) +2m
bittorrent-swarm tcp connect attempt to 127.0.0.1:38677 +0ms
bittorrent-swarm drain (0 queued, 0/55 peers) +1ms
@whit2333 Is it possible that you're behind a NAT that doesn't allow BitTorrent or something?
I have the same problem. I am behind a NAT (Saunalahti 3G modem). A normal bittorrent client does work for me, including DHT. WebTorrent seems to download a trackerless torrent, but seems to me (without doing a proper test) to take a little longer to get started compared to Transmission (it does get a lot of peers though). Perhaps a first step to figuring out what's going wrong could be to add some trace to ut_gittorrent?
Also it seems from a first read of the code + using Wireshark that get_peers is only sent once. (Although it looks like keepalives are sent every couple of minutes.) Perhaps any NAT udp connection tracking wonkyness could be mitigated by retrying a few times?
@frankier Thanks. Issue #5 will handle sending multiple get_peers(). Happy to get tracing added to ut_gittorrent
if DEBUG=*
isn't catching it.
Here is the debug output: