Max Inden
Max Inden
Unfortunately those logs don't help me much. Mind posting with `DEBUG` only, but from start to finish, i.e. startup of the server till timeout from libp2p lookup.
Sorry, late reply. > The strange thing is that `libp2p-lookup` manage to connect on the first try. But when i close and restart the server all the consecutive connections gets...
Thanks for the detailed report. > `[2022-06-21T20:37:40Z DEBUG libp2p_dns] Dialing /ip4/127.0.0.1/tcp/4002/p2p/12D3KooWDpJ7As7BWAwRMfu1VU2WCqNjvq387JEYKDBj4kx6nXTN` The listener, the dialer and the relay are running on the same machine, correct? I am confused why you...
`InboundUpgrade` has no way to tell who the sender is, given that the security handshake, and thus the authentication of the sender might not have happened yet. The only way...
> If it's not possible to provide `PeerId` information there, maybe it makes sense provide address info? Like multiaddr. Note that we are using the same `InboundUpgrade` and `OutboundUpgrade` across...
I am still a bit reserved to add an additional argument to `OutboundInboundUpgrade` for the sake of debugging. Would it not be an option to return an error from `OutboundUpgrade`...
I am only aware of https://github.com/libp2p/rust-libp2p/blob/master/docs/release.md and https://github.com/libp2p/rust-libp2p/pull/2780. I am in favor of adding additional information for newcomers. The only thing I would like to watch out for is not...
Why is `libp2p-dcutr` wrapped in a `Toggle`? Is it enabled on both dialing and listening client? ``` rust pub dcutr: Toggle, ```
Off the top of my head I can not think of a scenario where this error would be emitted. In the case where the remote does not support DCUtR it...
@ozwaldorf can you post a larger snippet of your logs? The final line might indicate that an incoming connection did end up being established.