838411 - WebSocket message send blocked by Avast 7.0 Network Shield

Status: RESOLVED INVALID

(Core :: Networking: WebSockets, defect)

Description

[Jakub Czerny]

WebSocket object doesn't send any message it accepts using "send()" method. Connection is properly established and can also be properly closed. "send()" method call doesn't throw any exception, 'bufferedAmount' property gets raised to correct value. However Firefox doesn't send any packet into system network layer (according to Wireshark observation). 

Steps to preproduce:
1. Go to http://www.websocket.org/echo.html .
2. Press 'Connect' button. ('CONNECTED' appears in log)
3. Press 'Send' button. ('SENT: Rock it with HTML5 WebSocket' appears in log)
   However next line 'RESPONSE: Rock it with HTML5 WebSocket' should appear too.

Notes:
- It works fine in Chrome, IE and Opera.
- It works fine with secured connection (wss://)
- Same bug seems to be in Firefox Nightly (21.0a1 (2013-02-05))

Comment 1

[Patrick McManus [:mcmanus]]

Jakub, thanks for the report.

Unfortunately this is WFM (works for me) in win 7 using FF 18.0 and nightly 21.

Can you try with a fresh profile?

Comment 2

[Jakub Czerny]

Bug appears (for me) on:
- Win8 x64 Firefox 18.0.1 (even with new profile)
- Win8Pro x64 Firefox 18.0.1 (even with new profile)

Bug doesn't appear on:
- Win7 Home Premium x64 Firefox 18.0.1
- Fedora 18 x64 Firefox 18.0 (rpm version)

... so it looks a bit like a Win8 specific bug.

Comment 3

[Jason Duell]

IIRC Honza said he had a win8 box and would try to verify this is an issue.

Comment 4

[Honza Bambas (:mayhemer)]

I just tried to reproduce on Win8 32bit box and it works for me (Nightly,Aurora).

Maybe this is related to 64bit system somehow, that I don't posses.

Comment 5

[Honza Bambas (:mayhemer)]

Could any AV or firewall rule be involved?  I want to eliminate any local setting that could cause this on your win8 installation before I order win8 license.

Comment 6

[Honza Bambas (:mayhemer)]

Tested with Win8 x64 Pro clean install (Build 9600, unupdated/fully updated) in VirtualBox, cannot reproduce.

Are you using 64bit build of Firefox? (That is btw unsupported).

Comment 7

[Honza Bambas (:mayhemer)]

(In reply to Honza Bambas (:mayhemer) from comment #6)
> Are you using 64bit build of Firefox? (That is btw unsupported).

Tested with that too, works for me.

Comment 8

[Jakub Czerny]

The failing combination is Win 8, Firefox (both 18 and Nightly) and 'Network Shield' of 'avast! Free Antivirus 7.0'.

Now I'm unsure whom should I report this bug to.
* It is malfunctioning with avast only so it looks like it's problem of avast. If this is the case, I'm sorry for my confusing report.
* However other browsers (Chrome, Opera) work fine. So maybe it would be interesting to tweak Firefox networking a bit.

Comment 9

[Honza Bambas (:mayhemer)]

(In reply to Jakub Czerny from comment #8)
> The failing combination is Win 8, Firefox (both 18 and Nightly) and 'Network
> Shield' of 'avast! Free Antivirus 7.0'.
> 
> Now I'm unsure whom should I report this bug to.
> * It is malfunctioning with avast only so it looks like it's problem of
> avast. If this is the case, I'm sorry for my confusing report.
> * However other browsers (Chrome, Opera) work fine. So maybe it would be
> interesting to tweak Firefox networking a bit.

Thanks for info.

I'll try to install 'Network Shield' of 'avast! Free Antivirus 7.0' in my testing win8 setup and check.

Comment 10

[Honza Bambas (:mayhemer)]

I can reproduce (Win8, avast! Free Antivirus 7.0 with a default install, Fx Release).

Will take a look.

Comment 11

[Honza Bambas (:mayhemer)]

Attachment: good and bad logs

Fx 18.0.2, timestamp,nsWebSocket:5,nsHttp:5,nsSocketTransport:5
Two logs, one with shield on (bad-) and one with shield temporarily off (good-)
Steps:
- go to http://www.websocket.org/echo.html
- click connect
- click send (leave as non secure)
- wait a little
- close firefox

In the logs I can see we are simply not getting nsSocketTransport::OnSocketReady

good-:
2013-02-19 19:17:18.120000 UTC - 0[280f140]: WebSocketChannel::CallAcknowledge: Size 28
2013-02-19 19:17:18.234000 UTC - 3472[280f530]: nsSocketTransport::OnSocketReady [this=282e2e0 outFlags=1]
2013-02-19 19:17:18.234000 UTC - 3472[280f530]: nsSocketInputStream::OnSocketReady [this=282e378 cond=0]

bad-:
2013-02-19 19:13:28.815000 UTC - 0[280f140]: WebSocketChannel::CallAcknowledge: Size 28
...and.. that's all, no OnSocketReady for the WebSocket's transport


By the way, we are also not able to disconnect (I assume web socket close is two way async?).  After a while (few secs) I get "Error: undefined" and the socket closes (I assume async close timeout?)


(Not contained in the log:) I also tried to turn the Network Shield ON while already connected and succefully echoed the server.  We are able to receive echos then.  However, while the shield is left on, if I then disconnected and connect again, we are no longer able to receive again.

Comment 12

[Honza Bambas (:mayhemer)]

Different scenario:
- [connect]
- [send]
- wait 10 secs (no answer)
- click [send] 5x quickly
- get all 6 answers!

Comment 13

[Honza Bambas (:mayhemer)]

Attachment: WireShark logs

search for 101 response

Comment 14

[Honza Bambas (:mayhemer)]

This is actually blocking send, not receive.  WireShard unhides this.

Comment 15

[Jason Duell]

Chatted w/honza on IRC: websocket handshake seems to go fine, but for some reason send() is getting blocked (and from comment 12, sounds like it's not dropped but queued for some reason by avast).  Honza looking into trying to see if Chrome's send() format differs somehow from ours.

Comment 16

[Honza Bambas (:mayhemer)]

Jakub, can you please check a test build at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-8472365d1fb5/try-win32/firefox-21.0a1.en-US.win32.installer.exe ?

It should fix this issue.

Comment 17

[Honza Bambas (:mayhemer)]

Attachment: v1

- just not merging the connection header value
- according wireshark logs ie10/chrome-rel don't add to the connection header nothing more then just "upgrade" as well

Comment 18

[Jakub Czerny]

(In reply to Honza Bambas (:mayhemer) from comment #16)
> Jakub, can you please check a test build at
> http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/honzab.moz@firemni.
> cz-8472365d1fb5/try-win32/firefox-21.0a1.en-US.win32.installer.exe ?
> 
> It should fix this issue.

http://www.websocket.org/echo.html works ok for me using this build.

Comment 19

[Honza Bambas (:mayhemer)]

Comment on attachment 716029 [details] [diff] [review]
v1

https://tbpl.mozilla.org/?tree=Try&rev=f7dee7232a7e

Comment 20

[Jason Duell]

Patrick:  I'm Ok with the fix here, but given bug 730742 comment 1 and 4, I'm guessing you'd be happier turning this into an evangelism bug to have Avast change their server?  (The issue here is exactly the same: Avast barfs on "Connection: keep-alive, upgrade").

Do we really expect to encounter many cases where we try to set up a WS connection, it fails, and then we reuse the HTTP connection?  Seems likely that many servers might not actually handle the HTTP reuse in that case well?

Comment 21

[Jason Duell]

The other argument for relenting here is that we'll spend less developer time chasing these down in the future...

Comment 22

[Patrick McManus [:mcmanus]]

Thanks honza and jason!

I've filed a bug with avast pointing them at this bug (hi avast!). Its a private ticket system so no link here.

Its always a hard call about whether or not to ship a workaround or wait for the other end to fix the problem. In this case the bug isn't a big problem yet so I think we should try and go for the pure standards approach and have Avast fix their bug. Afterall they are a 'transparent' proxy and so are very dependent on standards compliance so I hope and expect they will be a kindred spirit here.

The workaround is no big deal, but lets try and avoid another "unwritten rule of the web" that we don't know when we can jettison. The other bug about not erroring on content-length really drives that home for me. So I'd rather not commit the patch - but if we do want to commit something its certainly the right one.

other opinions?

Comment 23

[Jason Duell]

OK let's mark this INVALID for now until/unless we're convinced the web needs the workaround.

Comment 24

[Patrick McManus [:mcmanus]]

kev, I heard you might know of someone at avast that you can make aware of this..