I think what weâre seeing here isnt Valve messing up but rather the middle east conflict expanded to cyberspace and spilling over to impact civilians. Look at the timing and affected countries. China isnt also exactly known for free internet.
WebRTC works as fallback. WebRTC is encrypted and cant be used for much else.
STUN in the otherhand is unencrypted and the protocol itself can be used for DDoS reflection/amplification. I would not be surprised if this is somehow weaponized and/or blocked/analyzed in real time that then breaks the connectivity.
STUN/TURN is basically icanhazip for WebRTC. STUN gives you your public IP:port. TURN is the same, but the returned IP:port is the one that had been dynamically allocated to you at time of querying, rather than the actual ones.
WebRTC clients take that STUN/TURN response and send to peers through out-of-band, through e.g. a lobby server chat mechanism, to set up the connection. This allows NAT table entries to be created as if they are outbound connection at both ends.
You can't make P2P connection with STUN/TURN alone. STUN/TURN is just a tool required for WebRTC.
TURN is the last resort and isn't just signaling. It carries the traffic as well.
If you can make all the STUN servers fail from the perspective of the clients, you could hypothetically force them to use TURN servers that are more centralized and easier to spy on. STUN negotiates pipes n:n. TURN is closer to n:1.
> force them to use TURN servers that are more centralized and easier to spy on
Webrtc traffic is encrypted as it travels through the TURN servers, isn't it? Sure, you get some which-ip-contacted-which-using-what-service metadata, but any active middleman able to mess with STUN traffic already has that.
It could just be that someone's fucked up a setting somewhere. I mean, the reason WebRTC has loads of options for 'interactive connectivity establishment' is because it's common to see users behind NAT, users whose NAT cant be traversed with STUN, IPv6 being broken, UDP getting blocked, TCP ports other than port 443 getting blocked, etc etc.
If a country's ISPs use CGNAT to avoid giving users precious IPv4 addresses, and world events made the ISPs turn the security settings up to 11, STUN just stops working.
> TURN is the same, but the returned IP:port is the one that had been dynamically allocated to you at time of querying, rather than the actual ones.
I don't know you mean by this, but I think you're confused. I have implemented STUN, so I know how it works. AFAIK, TURN doesn't reveal an address/port any different from that revealed by STUN, and cannot, because its discovery feature is STUN. (Also, a typical home user has only one internet-facing address, not a dynamic one plus another one.)
Rather, TURN provides a STUN address/port discovery service and a data relay service. The relay is for cases where two peers wishing to connect are both behind difficult NAT, meaning there is no quick and reliable way for them to directly connect even when they have their STUN results. So instead of connecting directly, they communicate through the relay.
I admit that I only have rudimentary understanding, but: my understanding was that TURN uses a modified STUN format that returns the address/port on the peer facing side of the TURN server, a la address of a hotel room or PO box, of querying user. My point is that STUN/TURN(especially STUN) are not encapsulation protocols for WebRTC, but just means to determine(or get assigned, so TURN sort of is encapsulating, by being a transparent proxy) client's own public IP/port because there is no way to do so than by asking someone with a global IP.
I think you have that backwards, WebRTC doesn't work, and STUN does.
I think you have it sideways. STUN [1] is the NAT traversal / "NAT hole punching" process that allows peers to discover their public IP addresses and establish direct P2P bidirectional UDP communication. WebRTC depends on STUN to establish P2P communication. You may be thinking of TURN [2] which amounts to routing traffic through an intermediary node that is visible to the two peers.
[1] https://en.wikipedia.org/wiki/STUN
[2] https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_...
We do P2P in our networking software and this is why we do it all in band instead of using STUN, TURN, or other common methods. Those get blocked and theyâre also often insecure.
STUN has mitigations now against being weaponized but itâs still a shit protocol. The fact that neither STUN nor TURN contain any way whatsoever to accomplish any kind of rendezvous without yet another signaling path boggles my mind given how easy it would have been.
> The fact that neither STUN nor TURN contain any way whatsoever to accomplish any kind of rendezvous without yet another signaling path boggles my mind
Interesting. Can you expound on this a bit? How does ZeroTier do it?
ZeroTier has "roots," which are nodes that relay packets and also tell you what your IP info is. Everyone in the world connects to a pool of these.
Other than relaying and STUN-like IP info reflection, they're dumb and do very little. They can't see your traffic or other information or even what virtual networks you're on.
Once both sides learn their external info, they communicate via the root to arrange P2P rendezvous. If both have IPv6 they use that, but still do a hole punch due to stateful firewalls. But with V6 it works almost 100% of the time. If one or both have V4, they do more cumbersome V4 hole punch maneuvers.
Our next-gen product, which is still in pre-release and has been shown only to some enterprise customers, is called ZeroTier Quantum. It's called that cause it's built on PQC (pqNoise to be exact) but it's also a full-scale reengineering of the whole system. But it still uses very similar techniques. Everything is in-band. No STUN, TURN, or even DNS dependencies.
I developed WireGuard-like P2P VPN on WebRTC and performance was great 300Mbps+
I think we can align on WebRTC for realtime P2P gaming and enterprise networking and more, instead of IPs base solution as end-users will not need to figure out firewall issues and IPv4/IPv6 differents
I know I'm just preaching to the choir here but my favourite thing about open source/published source libraries/applications is discussions on bug reports/pr's like this.
It's just something so heartwarming of multiple people coming together to describe their symptoms, workarounds and theories of what could be causing it.
GitHub discussions used to be so much higher quality though when the platform was for professionals. Now, I see so many discussions that devolve into practically being reddit/4chan threads. Another reason to leave.
Only on those posted to social media including Hacker News. There is no devolving into memes for niche discussions only interested parties know about.
Donât blame Github for getting spammed whenever an issue reaches the front page.
I wish HN would ban posting links to issue trackers with comment sections, like lobsters has done. Although the spam volume from HN and reddit is pretty small compared to that from youtube reaction video influencers
Not only. I see it across all of GitHub. Spam, +1 comments, feature begging are all particularly common.
Eternal September.
> when the platform was for professionals
I feel like it's gotten more professional. 10+ years ago people were dropping the hard R in pull request reviews, now everyone is acting like LinkedIn-speak and Stars will get them their next job
...What? Is this the Linus Sebastian misconception of what the hard R is?
Title does not match GitHub issue: "Major P2P issues in Israel and possibly other middle east countries"
Wild hypothesising here on HN but if you read to the end of the GH issue users have been reporting that STUN has been failing (i.e. no P2P link establishment, fallback to high-latency relay servers.) Multiple users have been able to work around the issue by manually substituting older Valve WebRTC dlls. I'd love to read a postmortem from the Valve devs.
Valve fascinates me because the devs there occasionally seem to be simply the best on earth in a given field, but despite that, bizarre bugs will persist for a long time. My favorite was how steam in home streaming from a PC to a steam deck wouldn't work if the steam deck had an Ethernet and wifi connection - one of the connections had to be disabled or the stream would always crash.
Maybe they need a few average devs there to spend time sweeping up behind the paragons that are pushing the envelope into these features existing at all.
The company is very small, and they're doing a lot with what they have. Steam alone is full of arcane features that I keep discovering. There's a lot of backend stuff. They're making games and hardware.
Perhaps some of this is contracted, similar to the Linux compat and drivers, but it's still impressive to me, compared to the orgs like Spotify, order of magnitude larger with barely any features at all. (I understand there's legal, huge backend, and I didn't see many bugs over time, but still)
The company makes $50,000,000 for every employee each year. It can afford more employees.
But would it actually help. More employees means more communication and overhead. Lean organisations can move much quicker. Part of why valve can do what valve does is how lean it runs.
No doubt they can, maybe they should. My point is that I'm more impressed with the results than many other companies that I know.
The number of developers needs to grow log(n) to the number of users to handle all error reports. Valve is way under the log(n) of user.
Valve famously has a very flat org structure so it's possible that that problem just isn't sexy enough for someone to pick it up on their own, without being told by a higher-up.
I wish they offered remote; I'd happily work there doing those sorts of unglamorous bug fixes. High-reliability engineering is my jam.
People keep blaming the flat org, as if conventionally-organised companies never had any bugs or never focused on very visible and marketable features rather than bug fix.
In fact, the flat org allows a random person to work on a niche bug management doesnât seem to care about, which wouldnât be possible if you had a boss breathing down your neck.
They say they have a flat structure. People who have worked there, despite some axe-grinding, indicate otherwise.
grug tribal animal, tribe always there even when chief say is not
My favorite bug family, that somehow to sneak in every time, is how their react frontend (or whatever the store runs) manages to semi-crash and the controller inputs are no longer recognized.
I kind of hope at least they'll fix such issues permanently before the steam machine release.
That is the bane of my existence. Steam's UI is so slow to react due to its web roots, that I feel like people must be insane to think that Steam is somehow this great app. It's terrible.
I shop on GOG.
Steam was rewritten in React relatively recently. I think most people formed their opinion of Steam back when it was mostly developed in VGUI, the same in-house native UI framework Valve used in games for stuff like the Half-Life 2 title screen and the TF2 server browser.
> Steam's UI is so slow to react due to its web roots
I actually wouldn't blame the web roots. Battle.net is also a CEF based launcher and it feels so much more snappy compared to Steam. For some reason Steam just feels really slow.
> in Israel and possibly other middle east countries
Why did you leave this part of title out? For clicks?
Or maybe because if there is one thing the world doesn't need, it's yet another thread devolving into flamewars about the Israel/Palestine conflict?
Then don't make this thread. One can't discuss an issue about Israel/middle east's internet connection while pretending the war doesn't exist. Technical issues don't float in a perfect vacuum sphere.
> Technical issues don't float in a perfect vacuum sphere.
I agree. But if there is a chance to not immediately draw in the wrong crowd... I prefer if people take it.
You've been here long enough to understand that would exceed the title character limit.
I just tested it. Copied&pasted the original title into submit form.
Nope. Right within the limit.
[flagged]
It's so funny when people come up with these arguments so confidently and then seeing them getting disproved so quick. Bro was never more glad there's anonymity on the internet
What an absolute dud of a submission, I can't believe this got so many upvotes. I guess people saw "Valve" in the title and figured it must be important, even though the content of the issue doesn't even line up with the title.
The rabbit hole started as a major P2P issue in Israel and possibly other middle east countries and further investigations revealed it seems to be a worldwide problem.
worldwide means israel russia and china so far. all countries that dont exactly like internet freedom and have a long history of spying and censorship. this might be a side effect of some government policy against p2p networks designed to make it harder to bypass censoring isps.
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.