Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Autonat + Quic Fails on Localhost #3308

Open
Tracked by #4524
dignifiedquire opened this issue Jan 5, 2023 · 5 comments
Open
Tracked by #4524

Autonat + Quic Fails on Localhost #3308

dignifiedquire opened this issue Jan 5, 2023 · 5 comments
Labels

Comments

@dignifiedquire
Copy link
Member

Summary

I have two nodes (iroh) running on localhost. When A dials B on quic-v1 and the autonat protocol is enabled the connection is established but killed again very shortly after, when autonat is disabled, the connection stays established

In the logs of the dialing node I found

2023-01-05T21:17:48.345168Z DEBUG libp2p_autonat::behaviour::as_server: Reject inbound dial request from peer 12D3KooWMgMs3K6DeWBRTmRGEk27h22ZZUh5r8FMs7isVHPCKZox: refusing to dial peer with blocked observed address.
    at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-autonat-0.9.0/src/behaviour/as_server.rs:144

and on the other node it gets into a state of printing these messages over and over again

  2023-01-05T21:23:23.933938Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
    at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

  2023-01-05T21:23:23.937812Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
    at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

  2023-01-05T21:23:23.939190Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
    at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

  2023-01-05T21:23:23.946320Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
    at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

  2023-01-05T21:23:23.947716Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
    at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

Version

  • libp2p version: 0.50.0
@elenaf9
Copy link
Contributor

elenaf9 commented Jan 5, 2023

In the logs of the dialing node I found

2023-01-05T21:17:48.345168Z DEBUG libp2p_autonat::behaviour::as_server: Reject inbound dial request from peer > 12D3KooWMgMs3K6DeWBRTmRGEk27h22ZZUh5r8FMs7isVHPCKZox: refusing to dial peer with blocked observed address.
   at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-autonat-0.9.0/src/behaviour/as_server.rs:144

Is autonat::Config::only_global_ips disabled? Default it is set to true, which will cause AutoNat requests to be rejected on localhost. But this is unrelated to quic, and also should not cause connections to close (unless no other behaviour exists and thus keep-alive is set to false).

and on the other node it gets into a state of printing these messages over and over again

 2023-01-05T21:23:23.933938Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
   at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

 2023-01-05T21:23:23.937812Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
   at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

 2023-01-05T21:23:23.939190Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
   at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

 2023-01-05T21:23:23.946320Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
   at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

 2023-01-05T21:23:23.947716Z DEBUG libp2p_quic::endpoint: Dropping packet for connection ConnectionHandle(0) because the connection's channel is full.
   at /Users/dignifiedquire/.cargo/registry/src/github.com-1ecc6299db9ec823/libp2p-quic-0.7.0-alpha/src/endpoint.rs:510

This is caused by the connection not being able to keep up with the inbound messages, e.g. because its task is not getting polled or the remote send the packets faster than the local peer can handle them. But should not be related to AutoNAT.

Nothing comes to my mind right now with just these logs. Could you share your code / steps to reproduce?

@dignifiedquire
Copy link
Member Author

The code is based on n0-computer/iroh#586

You can build the binary using cargo build -p iroh-share and then run

$ iroh-share send <some larger file>

which will print out a "Ticket" and in another shell run

$ iroh-share receive <ticket>

Autonat is controlled here: https://github.com/n0-computer/iroh/blob/17e037dc0ce55da105aab04542fe09e2c3b924e8/iroh-share/src/p2p_node.rs#L65

and the transport is built here: https://github.com/n0-computer/iroh/blob/17e037dc0ce55da105aab04542fe09e2c3b924e8/iroh-p2p/src/swarm.rs

@dignifiedquire
Copy link
Member Author

@dignifiedquire
Copy link
Member Author

Additional note: this does not happen when using the tcp address, same setup

@elenaf9
Copy link
Contributor

elenaf9 commented Jan 17, 2023

I haven't had time to look into this yet, but I am currently looking into an issue around closing streams in QUIC, see #3343. This issue might be related. Did you observe any error logs here around closing a stream?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants