Users who aren't pingable do not receive feedback on commands failing

[d34d10cc]

Version information:

go-ipfs version: 0.4.10-
Repo version: 5
System version: amd64/windows
Golang version: go1.8.3

Type:

Bug/Enhancement

Severity:

Medium

Description:

I'm not really sure I should be listing this here, but users who are not pingable due to e.g being behind a CGNAT do not receive any errors or general feedback while the commands they run are failing. As far as I understand, a massive time-out limit is in place for all commands so commands just hang and block additional console input. On Windows, at least, it is impossible to stop the running of the commands via conventional methods (Ctrl+C, etc). I am not sure this would be fixable without intervention from nodes outside the user's local network to ping the machine. If not, a warning should be put in place to prevent confusion, because a large number of people do not have access to unblocked, static IP addresses.

[whyrusleeping]

What sort of commands are failing with no errors? Are you sure its related to NAT and not something else?

[d34d10cc]

All commands that rely on p2p. For example, cat fails and cannot be stopped, but I can access the web interface if the daemon is running. Add fails too. I'm sure it's related to NAT since once I tunneled through a 6in4 tunnel I could use ipfs just fine.

[whyrusleeping]

ipfs add fails? That has nothing to do with any sort of networking though. Can you copy paste some command invocations youre running?

[d34d10cc]

My bad, I just tested again, it does work. On the other hand ipfs swarm peers only shows four servers (earth, pluto, venus...) and ipfs swarm connect fails like the others.

[Stebalien]

• ^C should work on windows, if not, let's investigate that in a new issue.
• We now have an AutoRelay feature that we're going to enable by default pretty soon. This will allow nodes to detect their NATs and, if present, setup a relay to allow incoming connections.
• --read-timeout option for ipfs get #5541