I have weird behavior when using https://zencastr.com/. The moment I join their videocall-room, my internet becomes super flacky, and drops entirely.<p>My connection is via WiFi, and the WiFi stays connected and everything, but no connection to neither zencastr.com, fast.com, google.com works.<p>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.<p>When I use a competitor tool, riverside.fm or google meet (both using WebRTC as well) I don't have any of this problems.<p>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?
Networking problems can manifest in odd ways. One of my favorite tech support calls was when an app I supported would consistently fail to load for a specific set of people in Northern Wisconsin who all worked for the same company but worked from home in different towns. They escalated the problem and "proved" that it was our app - every other site on the web worked just fine, but ours would not load. I don't fault their logic, but I knew our site was up and running just fine.<p>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.<p>So my approach has always been that if it makes no sense for software to be causing an observed problem - investigate the other layers.
Are you sure it's your network connection, and not just the browser? Maybe something zencastr is doing is triggering a bug in the browser that somehow affects other tabs, or the browser's underlying networking code? (This may seem unlikely with the multi-process architecture Chrome and Firefox use, but who knows.)<p>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.<p>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.
I've had (isp provided) modem+routers that get flakey or crash and reboot when there's certain network traffic. I did manage to get one replaced because a fragmented ipv6 packet would routinely crash it, and then in the replacement any ipv6 packet would take an absurd amount of time to traverse the router, but I 'fixed' that by running the modem as a pure bridge and running PPPoE[1] on my own systems.<p>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.<p>[1] Ugh, PPPoE is garbage, but my other choices are either worse or involve tremendous expense.
You may be experiencing a BufferBloat problem.<p>Try running this tool before, during and after you have problems: <a href="https://devina.io/speed-test" rel="nofollow">https://devina.io/speed-test</a>
Have you measured the bandwidth usage or packets per second when this happens? It is possible for websites to consume all available bandwidth. It used to be pretty universal that your internet connection was smaller than your Wi-Fi connection. This allowed various queuing and discard algorithms within your router to do their job and provide some sort of fairness to the various things competing for bandwidth. Modern internet connections can be 1gb or more which can far exceed what Wi-Fi can actually do. This kind of flips the mechanisms where the congestion is actually happening and can cause odd behavior.<p>Google 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.<p>It's really difficult to tell beyond some general speculation without some packet captures bandwidth graphs and packets per second measurements.
Lots of parts to WebRTC ( <a href="https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API</a> ) but none that I know that can knock out something outside of your browser. It could maybe overload RAM and get killed.<p>Try using the offending website on a browser/OS that _doesn't_ have WebRTC such as <a href="https://caniuse.com/?search=webrtc" rel="nofollow">https://caniuse.com/?search=webrtc</a>. Or try with WebRTC disabled.<p>Possible you're getting throttled by your router or ISP when certain connections are made.<p>And there's this <a href="https://browserleaks.com/webrtc" rel="nofollow">https://browserleaks.com/webrtc</a>
What have you done to debug it? There isn’t much information to go on here.<p>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.
Use a second machine (not connected to zencastr) to see if it is actually affecting your Internet connection or just the machine/browser that has loaded the site.
Definitely use wired connection and another device to rule out router problems. Find out what IPv4 gateway your router is using and see if you can ping that. Try pinging 1.1.1.1. Use Matt's trace route (mtr) to see if a particular hop along a connection is failing more than others.
On a properly working system, this should generally not happen, but there are sooo many things that could be going wrong.<p>I'd first try on a different WiFi that has <i>both</i> a different router and ISP. That should narrow down where you have to search for the problem.