bad behavior when localhost is down #1935

New Issue

warner · 2013-03-20T21:21:56Z

warner commented

2013-03-20 21:21:56 +00:00

User "amospalla" on IRC had problems setting up an introducer and a node on the same box (they reported that the node started, and the web ui was visible, but it could not connect to the introducer). The problem turned out to be that their loopback interface (lo, usually bound to 127.0.0.1) was disabled or unconfigured, leaving only en0 (which had some 192-net private address). The node created a furl with functional connection hints (I think telnetting to the 192-net address worked). But the node never reported connecting to the introducer. They were using "debian 7.0".

We don't know exactly what happened, but it sounds like something might accidentally depend upon having 127.0.0.1 be functional. I'd like to reproduce this on my linux box by doing "ifconfig lo down" and see what happens.

User "amospalla" on IRC had problems setting up an introducer and a node on the same box (they reported that the node started, and the web ui was visible, but it could not connect to the introducer). The problem turned out to be that their loopback interface (lo, usually bound to 127.0.0.1) was disabled or unconfigured, leaving only en0 (which had some 192-net private address). The node created a furl with functional connection hints (I think telnetting to the 192-net address worked). But the node never reported connecting to the introducer. They were using "debian 7.0". We don't know exactly what happened, but it sounds like something might accidentally depend upon having 127.0.0.1 be functional. I'd like to reproduce this on my linux box by doing "ifconfig lo down" and see what happens.

warner added the

labels 2013-03-20 21:21:56 +00:00

warner added this to the undecided milestone 2013-03-20 21:21:56 +00:00

zooko commented

2013-05-27 17:29:49 +00:00

See #1988.

Daira Hopwood <david-sarah@jacaranda.org> commented

2013-06-25 18:15:57 +00:00

In /tahoe-lafs/trac-2024-07-25/commit/a493ee0bb641175ecf918e28fce4d25df15994b6:

iputil.py: add tests for recent changes. refs #1381, #1988, #982, #1064, #1536, #1935, #898, #1707, #1918

Signed-off-by: Daira Hopwood <david-sarah@jacaranda.org>

In [/tahoe-lafs/trac-2024-07-25/commit/a493ee0bb641175ecf918e28fce4d25df15994b6](/tahoe-lafs/trac-2024-07-25/commit/a493ee0bb641175ecf918e28fce4d25df15994b6): ``` iputil.py: add tests for recent changes. refs #1381, #1988, #982, #1064, #1536, #1935, #898, #1707, #1918 Signed-off-by: Daira Hopwood <david-sarah@jacaranda.org> ```

daira commented

2013-06-27 02:13:08 +00:00

This needs re-testing; the way iputil obtains the local IP address list is now more tolerant of errors, but I don't know whether that is sufficient to fix this ticket.

warner was assigned by tahoe-lafs

2013-06-27 02:13:08 +00:00

daira commented

2015-03-27 10:47:44 +00:00

Note that as a side-effect of the fix to #754 (which will be released in Tahoe-LAFS 1.10.1), setting tub.location without including "AUTO" will skip the local IP auto-detection code entirely, thus allowing a workaround for this problem if the other changes on trunk didn't fix it.

Note that as a side-effect of the fix to #754 (which will be released in Tahoe-LAFS 1.10.1), setting `tub.location` without including "`AUTO`" will skip the local IP auto-detection code entirely, thus allowing a workaround for this problem if the other changes on trunk didn't fix it.

Sign in to join this conversation.