Wrong ports are reported for connected nodes

[genell]

In our friendnet all nodes are configured to use port 8098 as tub.port and in tub.location. This port is being forwarded through the firewalls of each node owner. Connectivity has been confirmed using nmap from the introducer node computer. In the WUI under "Address" some nodes appear to use 8098 as expected, but some appear to use random high port numbers such as 173.194.32.55:51265. These apparent port numbers also differ between the WUI:s of the different nodes. In some occasions the node has been presented as accessible in the WUI and has appeared to be using a port other than 8098, while neither 8098 nor the erroneous port has been accessible. Especially this last case is somewhat troublesome as the node appears online, but cannot receive data.

[daira]

In some occasions the node has been presented as accessible in the WUI and has appeared to be using a port other than 8098, while neither 8098 nor the erroneous port has been accessible. Especially this last case is somewhat troublesome as the node appears online, but cannot receive data.

Is it possible that the node made a connection at some point but the connectivity has changed?

[genell]

Replying to daira:

In some occasions the node has been presented as accessible in the WUI and has appeared to be using a port other than 8098, while neither 8098 nor the erroneous port has been accessible. Especially this last case is somewhat troublesome as the node appears online, but cannot receive data.

Is it possible that the node made a connection at some point but the connectivity has changed?

Yes, the node generally has made a connection at first, but fail to report broken connectivity when tub.port/tub.location is closed. We just did a test where port 8098 for one of the nodes were filtered in the firewall for about six hours. This was shown by our surveillance script testing 8098 connectivity using nmap, but the Tahoe WUI status page just showed the node as connected all through the six hours. I'd like to suggest incorporating some recurrent data flow test, where a tiny data file is uploaded as mutable and recovered back again from the cloud and if the operation fails it should be noted on the status page. Would that be possible/useful?

[zooko]

It already has such a periodic test, implemented by Foolscap. It is an application-level "ping", where Foolscap sends a message every so often and if the reply doesn't arrive Foolscap eventually times out and kills the connection. So, why didn't that happen in your case!?

[daira]

Is this a duplicate of #521 and/or #1997 ?

[daira]

Also see #1973, about confusing values in the "since" and "announced" columns of the Welcome page server list (which may or may not be a factor here).