DCUTR example not working #5741
Replies: 3 comments 8 replies
-
|
+1 |
Beta Was this translation helpful? Give feedback.
-
|
I should note that hole-punching is not guaranteed to success. It heavily depends on the real network configuration and topology. |
Beta Was this translation helpful? Give feedback.
-
|
Both the devices are behind a wifi router. I am able to establish the connection using iroh. |
Beta Was this translation helpful? Give feedback.
-
|
Yes so it seems like the hole-punching attempt is simply not successful. One common reason (apart from symmetric NATs) is that the timing when sending the outbound packets for the hole-punch is off. This may be because the round-trip time for the relayed connection is not consistent, or due to timing deviations when sending the outbound packets for the hole-punch. Especially when the rtt between the nodes is short, it is more important that the two nodes send the packets at the exact same time in order for the hole-punch to succeed. I am not familiar with the details of Irohs holepunching, but they are using QUIC as transport protocol while you are using TCP. |
Beta Was this translation helpful? Give feedback.
-
|
Are there any logs following the ones above? |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I should have been more I clear. I was wondering about the Dialer and Listener. Is there any more output/ logs following the ones that you posted above? |
Beta Was this translation helpful? Give feedback.
-
|
No these are the only logs available. Reciever
Dailer
Dailer stops after 3 attempts. |
Beta Was this translation helpful? Give feedback.
-
|
I am testing hole punching and relaying with three peers: A relay peer (using examples/relay-server), running on a cloud machine with public access. In my listener logs, I am unable to distinguish between relayed and direct connections. I’d appreciate guidance on which behavior event I should look for to make this distinction. Additionally, on the listener, I see the following log: INFO Connection closed peer=PeerId("12D3KooWDrAvsiX8hM5yVpDMrPEwSFRfQguLdBCVKgs********") Connection closed with error: Connection error: I/O error: connection is closed INFO Established new connection peer=12D3KooWR2KSRQWyanR1dPvnZkXt296xgf3FFn8135szya****** INFO dcutr_example: event=Event { remote_peer_id: PeerId("12D3KooWR2KSRQWyanR1dPvnZkXt296xgf3FFn8135szya******"), result: Ok(ConnectionId(3)) } INFO dcutr_example: event=Sent { connection_id: ConnectionId(3), peer_id: PeerId("12D3KooWR2KSRQWyanR1dPvnZkXt296xgf3FFn8135szya******") } INFO dcutr_example: event=Received { connection_id: ConnectionId(3), peer_id: PeerId("12D3KooWR2KSRQWyanR1dPvnZkXt296xgf3FFn8135szya******"), info: Info { public_key: PublicKey { publickey: Ed25519(PublicKey(compressed): e1ef2fe6f211f7399a8a6a55fdc811ee92ec7f1ee125942da87ef6595******) }, protocol_version: "/TODO/0.0.1", agent_version: "rust-libp2p/0.46.0", listen_addrs: [/ip4/{relay ip}/tcp/4884/p2p/12D3KooWDpJ7As7BWAwRMfu1VU2WCqNjvq387JEYKDBj4k******/p2p-circuit/p2p/12D3KooWR2KSRQWyanR1dPvnZkXt296xgf3FFn8135szya******, /ip4/127.0.0.1/tcp/62722, /ip4/172.16.190.51/tcp/62722, /ip4/127.0.0.1/udp/62989/quic-v1, /ip4/172.16.190.51/udp/62989/quic-v1], protocols: ["/ipfs/id/push/1.0.0", "/ipfs/ping/1.0.0", "/libp2p/circuit/relay/0.2.0/stop", "/ipfs/id/1.0.0"], observed_addr: /ip4/{dialer public address}/tcp/36661 } } |
Beta Was this translation helpful? Give feedback.
-
You can distinguish by checking the endpoint address with
What network behavior protocols are you using? Connections are generally only kept alive while they are needed by a network behavior. If you only use e.g. identify then the connection will be closed after the identify message exchange. |
Beta Was this translation helpful? Give feedback.
-
To add, you can also check the address for
It is likely that it been idling for too long. Idling could be due to no activity stream on the connections or that no connection handler signaled to keep the connection alive. You could change the idle timeout to your use-case using I would have to actually experiment with it again though (been using relays directly in some of the environments that dont support dcutr or upnp) but I believe that the direct connection is not actively used by other protocols right away while it is going through relay so while that direct connection might get something like identify through, it will likely sit idling if there is no other activity before the relay connection is dropped. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
hello, i am trying out the dcutr example.
I am using 3 different computers on 3 different networks. Please help
This is the error that i get:
Look up command
listner logs
Dailer logs:
Server logs:
Beta Was this translation helpful? Give feedback.
All reactions