On 8/14/2013 5:01 PM, Harald Barth wrote: >> The addresses in use are not a hint that there is a problem. > > I say it's a hint, but we might want a better hint. > > Can we somehow follow uuids when ports are changing because of NAT? I > mean after the first timeout, so we don't need to timeout again.
The file server already follows UUIDs when addresses or ports change. However, the file server doesn't find out the UUID until: 1. a new connection is attempted 2. a TellMeAboutYourself reply is received Its too late to prevent the firewall from closing the >> Nor is >> there is guarantee that sending the packets in an attempt to elicit a >> response is likely to prevent the traffic flow from being blocked. > > Can we detect if it "gets better"? Of course we should not send > an infinite number of packets somewhere. > > But if we _guess_ it's NAT/stateful-firewall and then starting to ping > say every 290 seconds and ending the ping if there is no response 3 > times in a row should not be that harmfull. You need to send a packet every 20 seconds and if it is a packet that is eliciting a response that response is duplicating the NAT pings the client may already be sending. One would like to track in the rx peer whether or not NAT pings are being received but the entire point of the selection of NAT ping packets being empty version responses is that they will be dropped on the floor with a minimal amount of effort. Any tracking of their receipt in the peer object would be a major new source of lock contention that must be avoided. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
