On Wed, 14 Aug 2013 23:01:23 +0200 (CEST) Harald Barth <[email protected]> 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. I mentioned in some other email that it's possible to have more robust 'detection', but I didn't think it was worth the effort. Trying to make such decisions by tracking behavior like that gets a little complex for the host package (which is already doing simpler things by comparison IMO, and is already quite complex). But yes, I think to some degree it's possible to detect NAT 'breakage' like that. But it'll never be 100% accurate. > The question is how to figure out if this actually makes things > better, but we won't know if we don't try. I volunteer for testing > such a patch, but I'd like to have a way of logging Do you have reasons to believe you would be affected by clients with bad NATs? Testing this I think isn't really useful under lab/artificial conditions; I mean, we generally know what will happen given specific conditions. So it's only really useful with 'real' clients and such. I have some code to do this; the tip of it is here <http://gerrit.openafs.org/#change,10147> / 72f90085503afafd1a5b7d510de0cf700b693865. You can either use that tree directly or apply the patches from gerrit 10144-10147. That implementation probably isn't what I'd want for an actual release, but it should be functionally equivalent to what I'd want to do. (Just, the interfaces and such I used are obviously just done quickly to test this out) -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
