OK so we have had an instance of Cells v2 running on a Windows server (2016) (in VMWare hosted VPS) on IIS for a couple of years now but unused and now we are planning to reuse it so have updated the Pydio version to latest (from a version last updated about a year ago). The built in upgrade or command line method didn’t work (new .exe downloaded but original one couldn’t be renamed) so manually swapped out pydio.exe old for new, ran and completed the upgrade, happy days, all seems to be working fine other than this following error being reported in Cells:
Obviously the server is up and working or the error message would not be seen!
As far as I can tell, all is working as expected, but the error message persists and of course needs to be addressed (whether a genuine issue or not).
Similar to a topic from 2019 but the outcome of that one was: it’s now fixed, upgrade to latest…
We also see the errors in dev tools console but as suggested in above thread, this can likely be ignored. The error constantly in our Pydio public facing site however, cannot…
Any suggestions on solving this one?
Interestingly we have also seen this on the Pydio demo instance, so I am wondering whether this is simply some internet connection problem warning feature but not necessarily reporting an actual or permanent issue or problem with a Pydio instance?
Hello @AndyS welcome to the forum.
If you are facing the issue on the demo, it is very probable that you have a firewall on your side that prevents WebSocket connections. Are you operating from inside a company network ?
Access to the websocket is pretty important for the Pydio user experience, so you have to fix this first 
Charles
Hi Charles, thanks for the reply.
Our instance is behind the company firewall but we have already been using Pydio without this issue previously, it’s only since the upgrade to latest version do we see this message (which we also see sometimes on the Pydio demo instance from more than one location/device).
Whether there is any extra connectivity requirements introduced in the last year that would need additional firewall rules, I don’t know.
I cannot see any actual functionality issues thus far since upgrade and basic usage tests, just this message about websocket connectivity issue…
I’m guessing that the upgrade (manual swap of cells.exe file) might be related but that doesn’t explain why this can also be seen sometimes on the Pydio demo instance?
Any thoughts or suggestions very welcome and let me know if you need any more info/logs for further debug (I have launched cells with production logging enabled but not seen anything that gives a direct error relating to what we are seeing thus far.)
[Edit] Sorry I misread your first comment re company firewall, to clarify, yes our instance is behind company firewall, but we are remote so access it from outside the FW. Pretty sure we have also tested without our VPNs enabled but still have same issue.
BR
Andy
From what I read, you did have the connection issue before. I you recently upgraded (i don’t have in mind when we introduced this exactly) the new feature is to actually warn you about the connection issue. So I really think that you just did not notice it before. => You have to find where the websocket is blocked.
If you look in your browser (chrome ?) at the Developer Console > Network > Weboscket, you will probably see a failing connection here
Thanks, the notification was not seen before upgrade but we’ll take a look in dev tools to find clues as to what is being blocked and where and report back.
So checking in dev tools you can clearly see some delays and failures connecting to event and chat websockets, but oddly most of these which appear to be the same connections are successful…I can see no IP addresses or domains associated with these errors that would point to any firewall rules…
Lots of:
A quick search points fingers as the browser client reporting mechanism but I’m sure that’s up for discussion…
Hello,
I’ve tested on a windows 2019 server and that works well, no websocket issue. However, I open directly the port of cells to public (not via IIS). So it could be the problem of IIS reverse proxy.
Will keep you updated with IIS reverse proxy
Quick update on latest troubleshooting steps tried:
- Bound Cells to internal network IP address as well as localhost 127.0.0.1 - no improvement
- Enabled Websockets in IIS (via Server Manager) - you might think that would be the obvious easy fix! Nope
- Added reverse proxy rewrite rule for outbound, only inbound was configured. No dice
- Enabled ARR via IIS Install Application Request Routing | Microsoft Docs
Not yet tried (or sure is relevant) IIS and Url-Rewrite: rewriting the outbound response contents - Microsoft Tech Community
I can see no reason our firewall would be blocking any connections as it appears to have a general rule to allow client server traffic through and no logs indicate any connection blocking…
Frankly I am still a bit confounded as to how everything appears to be working but this message still shows up and why the message says “…please make sure the server is up…”, if server was down there would be no website, error message or anything!!
TBC…
Hi,
Try to install “IIS: Websockets Protocol” from web platform intaller 5.1.
After installation of this module, the websocket should work
Thanks for the suggestion, these components are already installed (although initially ARR 2.5 and upgrade to 3 via the Web Platform Installer doesn’t work, have to manually d/l it), still getting the websockets connection errors. Seems there are still several possible causes; mal-configuration? ARR not supporting " permessage-deflate" ? ARR 3.0 not supporting the Sec-Websocket-Extensions header? or some other as yet unknown issue. Still trying to debug the errors in the browser console to ID the exact cause but it’s looking like the latter of the above suggestions, investigations ongoing, any more suggestions welcome!
Hi,
My Setup:
Cells (8282) ===> IIS (443) ARR3.0 ===> domain win2019.local
IIS uses self-sign certificate.
IIS ARR 3.0 has only one default rule.
Thnx for the reply. The above is essentially the same config as ours (although you appear to be locally hosting the cells instance). There are a few issues and questions still outstanding, namely the question over whether ARR 3.0 actually supports Websockets compression or not as mentioned in my previous post above, no workarounds seem to have helped to date.
The other detail that has come to light is the fact the our VPS provider is likely serving our IIS site via some apache proxy mirror (unbeknown to me until recently):
If this is the case then we have to demonstrate this issue to our provider and I have wasted 10’s hours investigating this “issue”.
OK so finally got round to solving this one and it was the firewall in the end, WS(S) are not forwarded by default and have to be added/enabled to the Path-specific Routing rule:
Of course anyone else experiencing this issue may have a different firewall solution/setup so have to adapt to their setup.
In this instance it is a Sophos solution so the relevant info came via this post:
https://community.sophos.com/sophos-xg-firewall/f/discussions/84592/when-will-websocket-be-supported/387726#387726
The fact that WebSockets forwarding wasn’t enabled on the server in the first place wouldn’t have helped but I got there in the end.
This topic was automatically closed 11 days after the last reply. New replies are no longer allowed.