warming 'websocket connection invalid' in new version chrome 15.0.8 74.106 #619

Closed
helxsz opened this Issue Nov 2, 2011 · 21 comments

Projects

None yet

10 participants

@helxsz
helxsz commented Nov 2, 2011

But today I found the things don't work properly. on the server side, there is a warming: websocket connection invalid debugs, and on the client I can't see anything.

The only change I found is the Chrome version is updated to 15.0.8 74.106 now, the old version Chrome is working well

@rlidwka
rlidwka commented Nov 3, 2011

Chrome was updated to websocket version 13.

You should update socket.io as well. Support of this version was added to socket.io about a month ago.

@Irrelon
Irrelon commented Nov 4, 2011

Hey, I'm seeing the same thing... I'm running socket.io@0.8.6 according to NPM.

Do we need the latest version from GitHub rather than NPM?

@Irrelon
Irrelon commented Nov 4, 2011

Also, here is my debug log:

debug - emitting heartbeat for client 20225576041857688854
debug - websocket writing 2::
debug - set heartbeat timeout for client 20225576041857688854
debug - got heartbeat packet
debug - cleared heartbeat timeout for client 20225576041857688854
debug - set heartbeat interval for client 20225576041857688854
debug - setting request GET /socket.io/1/websocket/20225576041857688854
debug - set heartbeat interval for client 20225576041857688854
warn - websocket connection invalid
info - transport end
debug - set close timeout for client 20225576041857688854
debug - cleared close timeout for client 20225576041857688854
debug - cleared heartbeat interval for client 20225576041857688854

Before this happens, things are ticking along just fine and data is being sent and received by both client and server. It's always after the "debug - set heartbeat interval for client" that it happens.

@Irrelon
Irrelon commented Nov 4, 2011

I've been delving into this some more and have come to an interesting point...

I've found that the connection dies (gets the warn - websocket connection invalid) after receiving a request from another IP address that is not my own directly to the websocket URL.

I traced the IP back to a pool owned by my ISP. It looks like if I browse to any site my ISP will follow up with a browse to it shortly afterwards... even if that is to a websocket URL. Once that occurs the socket dies.

I'm going to try and confirm that this is the case by blocking their IP and checking the result.

@Irrelon
Irrelon commented Nov 4, 2011

Yup, looks like after accessing the websocket URL (albeit using the http protocol rather than ws://) the websocket dies.

Any way to protect against this?

@Irrelon
Irrelon commented Nov 4, 2011

OK, I've now CONFIRMED that this is the problem. ISP is following up every URL with a call itself. Also, I've found some more info about WHY they're doing it... see http://www.talktalkmembers.com/forums/archive/index.php/t-63522.html

@Irrelon
Irrelon commented Nov 4, 2011

I've created a temporary fix for this... in /socket.io/lib/manager.js line 530 I added:

// If we have an id, check that the id comes from the same initial IP as the first one did!
if (this.transports[data.id]) {
    if (this.transports[data.id].req.connection.remoteAddress != req.connection.remoteAddress) {
        // The new connection comes from a different IP from the original one so drop it now
        console.log('Access to transport from third-party IP attempted from ' + req.connection.remoteAddress);
        res.writeHead(404);
        res.end('404');

        return;
    }
}

That code checks the original request against the new incoming one. If the IP's for each do not match then it rejects the request.

@vtk13
vtk13 commented Nov 23, 2011

coolbloke1324, please, specify the place for fix. Several lines before or after fix would be appreciated. Thanks.

@Irrelon
Irrelon commented Nov 23, 2011

Hey, I turned it into a pull request here: #624

Thanks!

@paisible

sudo npm update socket.io

Did the trick for me.
Thanks @rlidwka

@binocarlos

This was an annoying issue for me - so I looked at the pull request:

#624

Had fired up the app first time and getting erratic disconnects from my friends connection on TalkTalk - turns out they were pinging back to the same socket URL around 30 seconds later killing the connection...

The fix in the pull worked fine - every other browser / ISP has had no problems, app on port 80, socket on port 843...

Seems sensible to not allow a subsequent request to a socket ID that is from a different IP that the socket was originally allocated....

Happy because now I get to use this wonderful library without stupid ISPs and their spyware tactics getting in the way (but only because I manually inserted the pull : )

@cantlin cantlin added a commit to cantlin/socket.io that referenced this issue Sep 24, 2012
@cantlin cantlin Optionally drop requests to existing transport instances from IP addr…
…esses not matching the original request IP.

This addresses #619: socketio#619. It's a minor refinement of an earlier pull request by @coolbloke1324: socketio#624.

* Alter handleRequest() to optionally check if the request IP matches the stored request IP for the relevant transport instance, returning 403 if it does not.
* Add a somewhat half-arsed test to verify this works.
* Add a config param to .enable() this behavior: ``strict ip policy``
* Also add ``trust proxy header`` to compare using X-Forwarded-For headers instead of remoteAddress.
0b9ef20
@Irrelon
Irrelon commented Sep 24, 2012

@cantlin That is A.W.E.S.O.M.E. thanks for updating it! To anyone else reading this, use @cantin's version, it's more versatile now!

@privman privman added a commit to privman/socket.io that referenced this issue Oct 25, 2012
@cantlin cantlin Optionally drop requests to existing transport instances from IP addr…
…esses not matching the original request IP.

This addresses #619: socketio#619. It's a minor refinement of an earlier pull request by @coolbloke1324: socketio#624.

* Alter handleRequest() to optionally check if the request IP matches the stored request IP for the relevant transport instance, returning 403 if it does not.
* Add a somewhat half-arsed test to verify this works.
* Add a config param to .enable() this behavior: ``strict ip policy``
* Also add ``trust proxy header`` to compare using X-Forwarded-For headers instead of remoteAddress.
07088f0
@terrycojones

I just ran into this too, and spent some hours trying to figure out what was going on. As I read the above, I was wondering "which ISP? which ISP????" and then saw the TalkTalk link. I'm using them too :-(

@coolbloke1324 - thanks for all the digging! And @cantlin - thanks too ;-)

@Irrelon
Irrelon commented Dec 4, 2012

@terrycojones I dropped TalkTalk and paid Virgin to dig up my road and install a real connection. TalkTalk really does suck, especially since when I called them about this they couldn't even understand what I was talking about and asked me to "reboot your router" LOL.

My advice, drop TalkTalk... I went from ~0.9mbps to this: http://www.speedtest.net/result/2337743639.png

Rock on.

@terrycojones

@coolbloke1324 Whoah, nice. How much did you have to pay Virgin? We have fibre to the start of our road, but no further. I'm in the middle of nowhere, with rain on the old copper line, and get a mere 0.5Mb/s upload :-(

I'm going to mail TT. I know it wont do much/any good, but at least it's another registered dissenter. Recording the URLs my connection visits, ok, I can live with that (I even used to be an ISP), but actually visiting them..... that's potentially disastrous.

@Irrelon
Irrelon commented Dec 4, 2012

@terrycojones Yeah it rocks. Fastest internet I've ever used. I'm in the middle of nowhere too out in Norfolk. Literally have farmland round the corner from me :)

They had a box at the end of my road too. I paid them about £1,500 to dig up the road and install the line, then it's about £38 a month for the service I think. Ultimately I took the decision that trying to upload gigs of data and do business without a real internet connection was costing more than the install did. It used to take around 2 days to upload 1.5 gig.

I used to think 2mpbs was "fast". Now I can download 14 megabytes a second... lol it's like night and day.

If you are interested in getting a quote from them I got in touch via their "Cable My Street" service: GPMB-CableMyStreet@virginmedia.co.uk

The girl who handled my install is Alison Reid:

Alison Reid
Cablemystreet Co-ordinator
Virgin Media | 1 South Gyle Crescent Lane , Edinburgh EH12 9EG
Tel : 0131 477 5588
Email : alison.reid@virginmedia.co.uk

@terrycojones

Wow, that's great, thanks. I'm 11 miles outside Cambridge, with cows grazing in the field across the broken laneway in front of the house :-)

Thanks again. BTW, I just wrote to TT legal.

@mjadobson

I have this exact issue with Talk Talk. (Using v0.9.13.)

@Irrelon
Irrelon commented Mar 18, 2013

@Sugarstack Yeah it's just TT as far as anyone has reported. My fix or the more recent one from @cantlin will fix your problem, or in my opinion (just as I did) you should drop TT as this is unacceptable behaviour.

@kim3er kim3er added a commit to dogmacreative/socket.io that referenced this issue Sep 25, 2013
@cantlin cantlin Optionally drop requests to existing transport instances from IP addr…
…esses not matching the original request IP.

This addresses #619: socketio#619. It's a minor refinement of an earlier pull request by @coolbloke1324: socketio#624.

* Alter handleRequest() to optionally check if the request IP matches the stored request IP for the relevant transport instance, returning 403 if it does not.
* Add a somewhat half-arsed test to verify this works.
* Add a config param to .enable() this behavior: ``strict ip policy``
* Also add ``trust proxy header`` to compare using X-Forwarded-For headers instead of remoteAddress.
8792d47
@kim3er kim3er added a commit to dogmacreative/socket.io that referenced this issue Sep 25, 2013
@cantlin cantlin Optionally drop requests to existing transport instances from IP addr…
…esses not matching the original request IP.

This addresses #619: socketio#619. It's a minor refinement of an earlier pull request by @coolbloke1324: socketio#624.

* Alter handleRequest() to optionally check if the request IP matches the stored request IP for the relevant transport instance, returning 403 if it does not.
* Add a somewhat half-arsed test to verify this works.
* Add a config param to .enable() this behavior: ``strict ip policy``
* Also add ``trust proxy header`` to compare using X-Forwarded-For headers instead of remoteAddress.
96f5098
@brandon-lockaby

I learned of this problem today, with a TalkTalk customer experiencing random disconnections, turns out his sessions were being stolen by the snooping ISP. What's blocking a resolution for this issue? Is a different solution needed?

@kim3er
kim3er commented Nov 9, 2013

It is frustrating that this is not part of the main repo.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment