allow [connections] tcp = none
? #2824
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#2824
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
str4d remarked that you can't set up an i2p-based client without also configuring Tor. I don't know the exact problem, but one that I can think of is that there are only two legal values for
tcp=
(either the defaulttcp
, ortor
), and--hide-ip
requires that it not betcp
. And you can' settcp = tor
without havingtxtorcon
installed.I'm wondering if we should add
tcp = none
, which would disable (ignore) TCP-based hints entirely.I'm undecided about whether
--hide-ip
should settcp = tor
ortcp = none
(see #2820). We've discussed having some other client-oriented create-node CLI argument that says "I want a Tor-kind-of node", or i2p, and if we had such a thing, it'd be a good indicator of whattcp=
should be set to. (if we're also setting up a server node, then the--listen=
argument might be a good indicator of what the user wants from their client, or maybe we should go back to having a simple--tor
or--i2p
argument that says "whatever else I've asked you to do, do it this way").It might also be a good idea to update the server-status section of the Welcome page to indicate when servers could not be contacted because of connection-hint problems. Like an extra status line, below the server-id, which shows "no tor plugin" if the FURL has only tor hints but there is no tor handler, or "tcp disabled" if the FURL has only tcp hints but tcp has been disabled.
I'm putting this in the 1.12 milestone so we can decide if we want it, to make i2p setup better. If we find some other solution, I'm happy to push it out to a later release, or not implement it altogether.
I think this is a good way to go, although I'm going to use
tcp = disabled
instead oftcp = none
, to match the way we're disabling things in the rest oftahoe.cfg
. Patch incoming.In a638a97/trunk:
There is still a usability issue: if the user forgets to set
connections:tcp=disabled
, the resulting error does not inform them of this, instead telling them to enable Tor.Opened #351 for updating the error message.
In e82e2c3/trunk: