#2339 closed defect (somebody else's problem)

Enable specific ports for running tests

Reported by: cipherpunks Owned by: daira
Priority: normal Milestone: undecided
Component: code-network Version: 1.10.0
Keywords: firewall tests foolscap Cc:
Launchpad Bug:

Description (last modified by daira)

With a restrictive firewall that blocks traffic to localhost (or 127.0.0.1) except for specific ports --such as the one in Tails-- it is not possible to run the test suite as it tries to connect to random ports on localhost.

For instance:

tahoe debug trial --rterrors allmydata.test.test_web
[ERROR]
    test_blacklist ... Traceback (most recent call last):
Failure: twisted.internet.error.ConnectionRefusedError: Connection was refused by other side: 111: Connection refused.

Change History (3)

comment:1 Changed at 2014-11-21T23:48:12Z by daira

  • Component changed from unknown to code-network
  • Description modified (diff)
  • Keywords foolscap added
  • Owner set to daira
  • Status changed from new to assigned

comment:2 Changed at 2014-11-21T23:50:55Z by daira

leif suggested that we might do the loopback tests over Unix domain sockets, rather than TCP. This requires foolscap to be able to use Unix domain twisted endpoints, but it would be nice to allow that in any case. There are potential failure modes that occur for TCP sockets but not Unix domain sockets (and vice versa), but we could potentially allow the tests to run either way without too much effort, if the test framework is properly abstracted.

comment:3 Changed at 2020-01-17T15:43:38Z by exarkun

  • Resolution set to somebody else's problem
  • Status changed from assigned to closed

I don't think that Unix domain sockets instead of TCP is a legitimate solution here. Unix domain sockets are not TCP sockets. They do not behave identically. To the extent that either a Unix domain socket or a TCP socket can be used in the test suite, it *needs* to be a TCP socket. For tests the purpose of which is *not* to integration-test against the OS network stack, neither Unix domain sockets nor TCP sockets should be used. In-memory test doubles can be used instead.

All that said, I don't understand what the ticket summary or description is suggesting or implying. The test suite doesn't control what TCP ports on localhost will be connectable. The environment of the test runner controls that. If someone wants to run the test suite, they need a suitable environment. Right now that environment is "ability to listen on unprivileged TCP ports on localhost and then connect to them". If Tails disallows this, Tahoe-LAFS itself can't do anything about that. The Tails operator must do something.

My best guess at the suggestion in the ticket summary is that it should be possible to configure the test suite to only listen on certain TCP ports and then Tails can be configured to allow these to be listened on and connected to. If that's the case, I'm not sure why Tails can't be configured to just allow the full ephemeral range.

Please feel free to re-open with a clarification on that point, if one seems warranted.

Note: See TracTickets for help on using tickets.