id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	launchpad_bug
1988	"don't stop the process if you can't execute ""ifconfig"" or ""route.exe"""	zooko	zooko	"Currently, the tahoe-lafs process tries to learn its IP address by creating a socket ([source:trunk/src/allmydata/util/iputil.py?annotate=blame&rev=1b84612fdf6623885ad4999fa245f9c87ccb53f6#L101 iputil.get_local_ip_for()]), and also by executing either {{{ifconfig}}} (on unix) or {{{route.exe}}} (on windows) ([source:trunk/src/allmydata/util/iputil.py?annotate=blame&rev=1b84612fdf6623885ad4999fa245f9c87ccb53f6#L137 iputil code]).

Even if it doesn't learn its IP address, or if it learns and incorrect IP address, it can still work, provided that the other processes that it needs to talk to have announced ''their'' IP addresses and it is able to open TCP connections to them.

Now the problem is that if it can't execute {{{ifconfig}}}/{{{route.exe}}} successfully, then it stops the process.

This is the number one problem that prevents people from running Tahoe-LAFS on new platforms (#898, #1536, #1918, #1707). In fact, it may be the ''only'' thing that prevents Tahoe-LAFS from being portable to all sorts of unix-likes! It also causes various other problems due to security constraints (#982), and subprocesses being finicky (#854, #1064, #1381, #1935)

What if instead, if the call to the subprocess ({{{ifconfig}}} or {{{route.exe}}}) fails, that it logs this fact and then moves on. This would change the failure mode from the user's perspective from ""It stopped at startup"" to one of the following:

1. ""I can't connect to anyone.""
2. ""I can't connect to some servers/clients but can connect to others.""
3. ""I can connect to all servers/clients and everything works.""

I don't like, in principle, changing a hard ""stop loudly"" failure into a soft ""misbehave confusingly"" failure, but in this case it might be worth it. The thing is that the confusing 3-way failure mode from (partial) inability to connect to other processes already happens due to other reasons. We wouldn't be ''adding'' that failure mode, we would be converting certain situations (previously unsupported platform, {{{PATH}}} is set weirdly, security feature prevent access to {{{ifconfig}}}, etc.) from the hard-stop failure mode to the latter failure mode.

This ticket supercedes #854 and #1536. Oh! And I see that #1536 has a patch from mk.fg! Good..."	defect	closed	normal	1.10.1	code-network	1.10.0	fixed	iputil portability transparency review-needed