Ask HN: Can a website kill my internet connection? (WebRTC)
I have weird behavior when using https://zencastr.com/. The moment I join their videocall-room, my internet becomes super flacky, and drops entirely.
My connection is via WiFi, and the WiFi stays connected and everything, but no connection to neither zencastr.com, fast.com, google.com works.
The tool uses WebRTC for the call, hence I assume it might have something to do with that, but my assumption so far was always that a website I open in my browser does not have any effect to the underlying network stack or so.
When I use a competitor tool, riverside.fm or google meet (both using WebRTC as well) I don't have any of this problems.
My question: Is it possible that a bug in their WebRTC kills my internet? If yes, shouldn't that be prohibited by whatever security mechanism in my browser?
24 comments
[ 5.1 ms ] story [ 75.7 ms ] threadGoogle and I imagine other specialized sites do play some trickery with how they craft their TCP packets potentially to avoid some things like this. So it is possible that it's less a bug in their web RTC and more an optimization with the other sites that don't have this same behavior.
It's really difficult to tell beyond some general speculation without some packet captures bandwidth graphs and packets per second measurements.
(... sorry OOKLA, there's a new site replacing my browser's "Speedtest" bookmark!)
If it's the speed you're seeing the the site causing the problem, it makes me suspect that there is a issues with selective ack that could cause the issues you describe. Maybe some jitter or out of order arrival. Probably need to see some packet dumps to see how it's behaving and compare the ones that work well and the one that doesn't.
If I were you, I'd confirm if the issue continues if on wired ethernet, and investigate from there. I personally won't do conferencing on wireless anything, jitter and unnecessary latency are the death of interactivity; but a lot of people disagree with me, I guess.
[1] Ugh, PPPoE is garbage, but my other choices are either worse or involve tremendous expense.
Well, days of troubleshooting later and we found a common network segment they all hit somewhere in Wisconsin, and the owner of that physical network found a bad piece of hardware on a telephone pole. I forget the details of what the hardware was or why it threw a fit with our site but not others... but the bigger point is that there are many layers in a network, so while software might be the problem... it also might not.
So my approach has always been that if it makes no sense for software to be causing an observed problem - investigate the other layers.
Took far too long to figure out what was happening.
At the same place. No other files were affected.
I knew that there was nothing to interfere with an active data transfer in a PIX but nonetheless. I asked him to take a sniffer trace outside the PIX.
Indeed, one TCP segment just kept getting dropped and retransmitted. I extracted the data from that particular segment, zipped it as a file, and asked him to try transferring this, much shorter file. It failed.
And this was when I spotted that each time we’d attempt to transfer the file, the CRC errors on the receiving PIX interface incremented by one.
Replacing the cable connecting to that interface had alleviated the problem. Whether it was a cable quality or a cable just not plugged correctly, will remain a mystery, but that case was helpful to always remember that somewhere low enough everything digital is still analog. And yes, having layers in the architecture is very good.
Try doing internet-related things outside the browser, in order to rule that out. Use curl or wget from a terminal, for example. Try a different browser while this is happening. Hell, try a different browser in general and see if the same issue gets triggered with the different browser.
It's also possible that some traffic pattern that happens to occur on zencaster is triggering a bug in your router's network stack. If that's the case, it would (probably) affect other devices on the network, too, like another computer or phone.
Try running this tool before, during and after you have problems: https://devina.io/speed-test
I'd first try on a different WiFi that has both a different router and ISP. That should narrow down where you have to search for the problem.
Try using the offending website on a browser/OS that _doesn't_ have WebRTC such as https://caniuse.com/?search=webrtc. Or try with WebRTC disabled.
Possible you're getting throttled by your router or ISP when certain connections are made.
And there's this https://browserleaks.com/webrtc
Always binary search: rule out the browser by doing it a different way. Rule out the machine by trying it on a different device, etc etc.