Nat detection still has some unnecessary issues

[bzee]

@neo

This gave no output and just returned to the prompt. So I ran it again echoing the return value from the command. It gave a value of 12. But without knowing what that signifies I don’t know what it found

12 signifies it is private.

$ nat-detection --help
A tool to detect NAT status of the machine. It can be run in server mode or client mode.
The program returns with the following exit codes based on the network status:
- 10: Public NAT
- 11: Public under UPnP
- 12: Private or Unknown NAT

Did you forward TCP too? I would be curious what the output is with -vvvv.

@neo

And as a tool to detect if your nodes can be contacted it does not work.

I disagree with this partially. Yes, TCP vs UDP makes it technically broken, because it only tells you the TCP status while the node is using UDP. But it does detect reachability for a port very reliably ohterwise.

@neo

The whole reason this came about was the suggestion by Roland to use it to do the testing of connectivity, or at least suggested it based on my requirements which was the same as wanting to be able to check someone’s connectivity, that a client could connect to the node, or at least one of the nodes.

It might be an idea for us to add a probe command to the autonomi command to check if you can reach a specific node. For now, I think nat-detection with --port will already be a huge help to most people trying to predict their connectivity status when running a node.

@neo

But only being able to do tcp, means you cannot test upnp for all cases since its possible to have unpn for one of tcp or udp too. Any chance this can be corrected in the future?

Specifically for the UPnP implementation in libp2p, I consider the chances low . But, work is being done on AutoNAT v2 that fixes the UDP issue. (feat(autonatv2): Implement autonat v2 by umgefahren · Pull Request #1 · umgefahren/rust-libp2p · GitHub)

We’ve put our hopes on AutoNAT v2. Our current nat-detection is based on AutoNAT v1 and these issues you describe I also talked about here: NAT Traversal ETA? - #5 by bzee

I feel like nat-detection does what it can. The reason we made it as a separate tool is because we can’t run it as part of the node because we need to pick either TCP or QUIC for the node or it’s going to mix up all these protocols in the network. And we can’t use AutoNAT with QUIC, so that’s how we ended up with the current situation.