More info : I don’t have a firewall (except windows xp’s one).
Clement,
Could I ask two questions:
–What browser are you using when you access kaazing.me?
–Would it be possible to ask for a Wireshark trace of this test? This would make it possible for us to determine what is going on. Let me know if you need help with the Wiresharking.
–Jan Carlin
I’m using FF 4.0 bêta 8.
Important news : when acquiring wireshark trace I left kaazing hanging, trying to establish a socket… And it worked with avast web shield enabled !
Web shield seems to delay (not block) (about 20sec) the connection…
Sorry but after a few sec I thought it wouldn’t work, even after more time… This behaviour is less buggy but not perfect yet.
EDIT : do you still want the trace ? (I know how to use wireshark)
Clement
Could you please send me the Wireshark trace. I should be able to, at a minimum, tell you more about what is going on.
–Jan Carlin
http://fex.insa-lyon.fr/get?k=rqdDyjZPEabOFdQM8HV
First try : without web shield : works well.
Second try (there is a few blank seconds between the two) : with web shield. It worked with a 20 seconds delay (between the page loading and the first dynamic data coming).
This may be a shot in the dark, but could you try adding port 443 into the avast redirect settings to see if this may help? Open the avast gui, click settings, and go down to troubleshooting. I know you have tried the advanced settings in avast but I’m not sure which ones. Maybe try 8080. Another shot in the dark!
Clement
Looking at the pcap you supplied I see a 20 second delay (exactly in fact) between a failed native (FF 4 supports native WS if you turn it on) connect attempt (#1802) and our fallback emulation implementation (#1902). See #722 for a successful connection.
The reason that 1802 fails is that the 8 bytes the client ends the request with are not there. Sending the 8 bytes is done to be compliant to the spec, see http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76#section-4.1 point 26. Without these 8 bytes the Kaazing Server will not respond, which again is according to spec. Since this does not happen when web-shield is turned off, the cause of this appears to be that the web-shield blocks them.
The emulation succeeds, after the delay, because it uses a different protocol, which avast doesn’t appear to interfere with. The delay seems to be introduced by the browser.
I will bring this issue up with avast
–Jan Carlin
Kaazing Global Support
@Charyb I added 443 and 8080 to the “http ports” in troubleshooting. Same problem 
@Jan Carlin thx for the explanations. Let me know if you have more informations
Sorry about that. It was I shot in the dark. I was wondering if websockets used a different port other than 80 and found 443.
There is an Avast pre-release update 5.1.874 if you would like to try it out. http://forum.avast.com/index.php?topic=68927.0
I have no clue if anything included in the update would help this or not.
jan.carlin has a good idea of what is going on though.
I have installed the new beta avast as you proposed. Same problem…
I can confirm this is indeed happening. I spent many useless hours reviewing code that was perfect, but it all suddenly stopped working, no matter which Web-browser I used.
At first I unwillingly suspected that I somehow broke the code. But it turned out that it was all failing thanks to Avast’s recent update. The Web-shield was identifying Websockets as a security risk.
Seeing as web-socket is a new technology and many developers are now starting to learn about HTML5, I think this move will frustrate a LOT of people that will probably never figure this out and will likely blame it on browsers or their own code.
While I’m relieved to finally know what the heck was happening, I found it very troublesome that Avast didn’t make it obvious that it was doing all of this behind the scenes.
If I -don’t- want websocket, I’ll use the latest public version Firefox or IE.
I honestly didn’t like this move. I’ll certainly be a lot more suspicious of Avast from now on.
Like the OP posted, exclusion isn’t working for us. We’re forced to turn off web-shield, which even I as the original developer, do it reluctantly. I can’t begin to imagine how I would go about convincing any potential users of my new websocket service to try it out, when the first thing they hear is that avast users should turn off WS if they want to try the system out.
And the log appears to says nothing…If I had something I trusted as much as I do avast, I would be switching AV right now. This sucks.
Hello,
I am working on a project using websockets and I noticed the exact same problem, when the Avast web agent is turned on, websockets do not work. Avast obviously blocks something which seems buggy because the Avast GUI does not show anything.
I tried http://kaazing.me/ on Chrome v 10.0.648.204, it does notwork at all when Avast is running. If I turn Avast off, it works.
Using Firefox 4 with websockets disabled the newsfeed works I guess it uses your fallback communication channel when websockets connection fails.
My project that uses websockets has the exact same behavior : works with the Web agent off, does not work with the Web agent on.
With no support in IE9 and support disabled in FF4 and Opera by default, almost noone will be able to use your project. Basically you are wasting your time.
With no support in IE9 and support disabled in FF4 and Opera by default, almost noone will be able to use your project. Basically you are wasting your time.
Thank you for your advice but my website is a full Flex website and I use a flash implementation of websockets, so it works wonderfully on any browser when Avast is turned off.
The problem remains with Avast, and strangely enough, Avasts seems to block websockets only when using Chrome. Worse than that, I don’t even get an IO error when trying to connect, but websocket messages just never reach the server when Avast is on, and about 5 minutes later, I finally get an IO error probably due to a timeout or something like that.
Anyway it would be nice if Avast was fixed before websockets become too popular.
This is an issue with Avast that has been discovered AND reported multiple times during the past 3 or 4 years. It has been like that on avast 4, and it’s still like that till today. I’ve been faced with this issue when I was building multi-player games in flash with a socket server.
Check this forum post I did over a year ago: http://forum.avast.com/index.php?topic=68270.0
Now that your reports say It blocks web sockets, it’s more than apparent that avast blocks stuff on port 80 that don’t seem like pure standard http web requests… (yes I tried too kaazing.me and it won’t work with the web shield on… but the split second i disable the shield, it comes to life).
Avast devs… this is a showstopper bug that’s been there for ages… do something!
Thanks for you sharing.