Comment 10 for bug 277063

The problem stems from the way the routes are set. In my case (two different subnets I am connected to , one wired at 192.168.2.0/24, eth0, and one wireless at 192.168.3.0/24, eth1), the routes get set as:

hggdh@xango2:~ $ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 192.168.2.1 0.0.0.0 UG 0 0 0 eth0
hggdh@xango2:~ $

So... there is a route specifically to 192.168.3.0/24, one for 192.168.2.0/24, and one *single* route to the world. So... when the plug is pulled from the single outside route, two things happen:

(1) any currently to-the world established connection is slowly fail: since there is a single outbound route, it will have, as a source IP, the local IP on the interface; since this IP is unrouteable elsewhere, it is probable that we will eventually get a timeout, but it is certain we will never leave the local node.

(2) the moment the interface is disconnected, n-m automagically resets the default route to the other interface. So *new* connections to-the-world will get the (new) source IP assigned to the surviving interface, and should work fine.

Although a good idea, the current implementation pretty much restricts usage to one single network (except for connections directed to one machine in the other network's address range).

I would be more useful (and increase survivability) if *any* of the networks could be used.