Alex Potsides
Alex Potsides
> Given that the final data read from the channel during the noise handshake is done by the client, it would be the one to close the connection. Actually I'm...
Waiting for 10+s between the dial and opening the ping stream doesn't help either. What I see on the JS side is that the outgoing datachannel is created, the `open`...
When running against go-libp2p I notice that the channel ids increment rather than being reused: ``` libp2p:ping:trace opened ping stream to /ip4/172.17.0.3/udp/49196/webrtc-direct/certhash/uEiAUK3Hpn0oJ_xXpVdNT_yZBqaAku-6BuINmBvAA1KSs8w/p2p/12D3KooWGH4cLF345t71KU1o7Hr9xwWz375W98Ek1sVWUwDFSJbC on stream outbound:4 +6ms libp2p:webrtc:stream:outbound:4:trace sending 32/32 bytes...
There is a [limit](https://github.com/libp2p/js-libp2p/blob/main/packages/transport-circuit-relay-v2/src/server/index.ts#L37-L40) to how many reservations a relay will accept - are you sure you're not hitting this limit?
Can you share a link to a demo project that shows the problem?
@2color no, there's another one 🙄 - https://bugzilla.mozilla.org/show_bug.cgi?id=1986138
> with the latest version of libp2p the timeouts for stream upgrades seems to be too aggresive This is probably an oversight that should be corrected. It's quite hard to...
@PradaJoaquin are you seeing this problem? Looking at the posted error logs the connection monitor closed the connection when the stream was reset by the remote peer during the connection...
cc @dozyio
@dependabot recreate