On 01/29/16 15:00, Stuart Henderson wrote:
$ curl https://owncloud.XXXXXXXXXX/apps/files_pdfviewer/js/previewplugin.js
curl: (7) Failed to connect to owncloud.XXXXXXXXXX port 443: Operation timed out
I have access to the logs and they show a mixture of 200 and 503
...and that pretty much matches the pattern I've seen connecting by
hand, so it's no big surprise that there are problems with the proxy
too.
Glad that you could reproduce the problem, I was starting to doubt my
own abilities with a 'simple' proxy.
If you have contact with any of the site admins see if they are
running on linux with tcp_tw_recycle=1, I think there is a strong
possibility that they are, and if so then they should fix their
configuration.
I wrote to our contact there and am trying to get the information if
they are using this setting.
They're likely to be breaking connections for NATted clients
too (and this is only going to get worse as more ISPs start
using CG-NAT for IPv4). The links in the above post have
detailed explanations.
OpenBSD uses this method which is described in RFC7323 sec 5.4
(OpenBSD's implementation predates this RFC by some years).
o A random offset may be added to the timestamp clock on a per-
connection basis. See [RFC6528], Section 3, on randomizing the
initial sequence number (ISN). The same function with a different
secret key can be used to generate the per-connection timestamp
offset.
There was a recent-ish change to the method used to generate the
offsets (MD5 to SHA512), I wondered if that had changed anything
so I've just checked from a 5.6 box, it does exactly the same -
if I make repeated connections to the owncloud box, some of them
fail.
Currently am not fully able to get my mind round the details in the
post, but if I read it correctly the machine running with tw_recycle has
problems associating connections correctly together because similar
host,port pairs but different timestamps. Shouldn't this cause problems
with all proxied or nated connections? Am simply asking as I somehow
can't fit it in that openbsd+squid shows this particular behaviour yet
{freebsd,debian}squid does not.
Thanks Stuart so far for what you have found and the patience to explain
it to me.
Cheers
Kim
