Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
HTML Client Remote TroubleshootingIf you're having trouble with remote HTML Client connections, here are some things you can try. | ||||||||
Line: 18 to 18 | ||||||||
This seems to be a problem for a number of remote users. The problem is packet sniffing firewalls, anti-virus, and routers that are not HTML5 ready. One of the big features in the HMTL5 client is the ability to run all of our traffic over the web server port. No more extra ports open in the firewall for Appx connectivity. The problem is that we are using an HTML5 feature called WebSockets to do this. The way WebSockets work is that you make a normal HTTP connection to a web server. Then at some point we upgrade that HTTP protocol to an WS (WebSockets) protocol to handle our traffic. WS is a layer on top of HTTP so it is still valid. Some hardware and software firewalls, routers, and anti-virus tools sniff network packets to make sure what is inside the packet is valid content for the protocol being used. Some of these tools have not added WebSockets as a valid protocol to be used on the web server port. So as soon as we convert our connection to websockets the hardware or software shuts down the connection. I know Avast is one that is problematic, also a CradlePoint MBR1000 router from 2011 seems to block websockets data over an HTTP port. | ||||||||
Changed: | ||||||||
< < | Here is a website that has a test for this issue. It websockets are allowed then the Server Time field on the page will update every second. If not it won’t. | |||||||
> > | Here is a website that has a test for this issue. If websockets are allowed then the Server Time field on the page will update every second. If not it won’t. | |||||||
https://websocketstest.com/ | ||||||||
Changed: | ||||||||
< < | If this is an issue there is another way to run the HTML5 client. Instead of running our websockets traffic throught the web server we can run it on an alternate port like the java client does. That means you will have to open an additional port in the server firewall to allow this connection. Doing this seems to make the incompatible firewall and anti-virus tools happier. The default is to open port 3014 from the outside world to the internal system that is running the server side of the HTML5 client connection (the server were "appxConnector.js" is running). Then you edit the client.html file to use this new port by setting… | |||||||
> > | If this is an issue there is another way to run the HTML5 client. Instead of running our websockets traffic throught the web server we can run it on an alternate port like the java client does. That means you will have to open an additional port in the server firewall to allow this connection. Doing this seems to make the incompatible firewall and anti-virus tools happier. The default is to open port 3014 from the outside world to the internal system that is running the server side of the HTML5 client connection (the server where "appxConnector.js" is running). Then you edit the client.html file to use this new port by setting… | |||||||
<meta name="appx-proxy-port" content="3014"> |
Line: 1 to 1 | ||||||||
---|---|---|---|---|---|---|---|---|
Added: | ||||||||
> > | HTML Client Remote TroubleshootingIf you're having trouble with remote HTML Client connections, here are some things you can try.Client doesn’t load or run correctly in my browser.This can be a problem if you don’t have good HTML5 support in your browser. We’ve had some users running very old OS and browser versions. One example, OS X Lion (10.7) was released July 2011. Since then there have been many major OS updates. 10.8 (Mountain Lion), 10.9 (Mavericks), 10.10 (Yosemite), and 10.11 (El Capitan). Safari in Lion probably is not the best HTML5 browser to use. Here is a website that grades your browser HTML5 support. https://html5test.com/My client connection keeps droppingThe “remote” indicator quickly goes to red after I load the html client page. This seems to be a problem for a number of remote users. The problem is packet sniffing firewalls, anti-virus, and routers that are not HTML5 ready. One of the big features in the HMTL5 client is the ability to run all of our traffic over the web server port. No more extra ports open in the firewall for Appx connectivity. The problem is that we are using an HTML5 feature called WebSockets to do this. The way WebSockets work is that you make a normal HTTP connection to a web server. Then at some point we upgrade that HTTP protocol to an WS (WebSockets) protocol to handle our traffic. WS is a layer on top of HTTP so it is still valid. Some hardware and software firewalls, routers, and anti-virus tools sniff network packets to make sure what is inside the packet is valid content for the protocol being used. Some of these tools have not added WebSockets as a valid protocol to be used on the web server port. So as soon as we convert our connection to websockets the hardware or software shuts down the connection. I know Avast is one that is problematic, also a CradlePoint MBR1000 router from 2011 seems to block websockets data over an HTTP port. Here is a website that has a test for this issue. It websockets are allowed then the Server Time field on the page will update every second. If not it won’t. https://websocketstest.com/ If this is an issue there is another way to run the HTML5 client. Instead of running our websockets traffic throught the web server we can run it on an alternate port like the java client does. That means you will have to open an additional port in the server firewall to allow this connection. Doing this seems to make the incompatible firewall and anti-virus tools happier. The default is to open port 3014 from the outside world to the internal system that is running the server side of the HTML5 client connection (the server were "appxConnector.js" is running). Then you edit the client.html file to use this new port by setting… <meta name="appx-proxy-port" content="3014"> instead of <meta name="appx-proxy-port" content=“80"> This causes the HTML5 client to use port 3014 for websockets data instead of port 80.I can’t install the local connector on my computer.This seems to be the case if someone is running a 32bit OS. Some users have upgraded very old 32bit hardware to Windows 7 32bit. In this case our local connector will not load. Our installer is 64bit and does not run on 32bit Windows. If this becomes an issue we can build a 32bit local connector for windows. Currently this isn’t a priority project. This is easy enough to check by looking at the Windows OS info screen.Comments-- Main.JeanNeron - 2016-02-10
|