Comments (6)
I noticed that accessing from chrome i get different/addtional logs (logs in previous message were from FF):
12:25:28.289821 handlers.go:25: stunner-auth INFO: static auth request: username="user-1" realm="stunner.l7mp.io" srcAddr=10.64.4.2:19946
12:25:32.735157 handlers.go:25: stunner-auth INFO: static auth request: username="user-1" realm="stunner.l7mp.io" srcAddr=10.64.4.2:20471
12:25:32.735378 handlers.go:25: stunner-auth INFO: static auth request: username="user-1" realm="stunner.l7mp.io" srcAddr=10.64.4.2:19757
12:25:32.928150 handlers.go:25: stunner-auth INFO: static auth request: username="user-1" realm="stunner.l7mp.io" srcAddr=10.64.4.2:20471
12:25:32.931463 handlers.go:25: stunner-auth INFO: static auth request: username="user-1" realm="stunner.l7mp.io" srcAddr=10.64.4.2:19757
12:25:32.931498 turn.go:239: turn INFO: permission denied for client 10.64.4.2:19757 to peer 89.25.216.14 (suppressed 1 log events)
12:25:32.931560 server.go:202: turn ERROR: Failed to handle datagram: failed to handle CreatePermission-request from 10.64.4.2:15570: no allocation found 10.64.4.2:15570:[::]:3478
12:25:32.931737 server.go:202: turn ERROR: Failed to handle datagram: failed to handle Send-indication from 10.64.4.2:19757: unable to handle send-indication, no permission added: 10.10.246.228:42681
12:25:33.697695 handlers.go:25: stunner-auth INFO: static auth request: username="user-1" realm="stunner.l7mp.io" srcAddr=10.64.4.2:19757
Not sure if important, but wanted to add 'just in case its meaningful'
from stunner.
Thanks for the clear problem description.
We've already seen this. The problem seems to be caused by that STUNner is running behind an nginx UDP proxy and, for some reason, every UDP packet we get seems to be coming from a different UDP source port. Since TURN identifies allocations by the IP 5-tuple (IP src/dst address, UDP src/dst port, and IP proto), this breaks the TURN state machine. In other words, for each TURN message (like CreatePermission
or a SendIndication
) that assumes a prior TURN message (like CreateAllocation
) received from the same 5-tuple, we get a no allocation found
error, like you see in your logs:
10:59:42.200586 server.go:202: turn ERROR: Failed to handle datagram: failed to handle Send-indication from 10.64.4.2:30068: no allocation found 10.64.4.2:30068:[::]:3478
Now, since this is the first time STUNner gets a TURN message from the UDP source port 30068 it tries to look up the corresponding session state but, it fails to find anything so it signals an error.
We never really debugged what causes this, nginx or the kube-proxy or some weird interaction between the two, but it seems that STUNner behind nginx does not work.
There are various possible workarounds:
- Find the magic config that will enable UDP connection tracking in nginx. I'm no nginx expert, so I dunno whether such a thing exists.
- Remove nginx from the loop and expose STUNner directly: this will also reduce your latency/jitter, but if you include nginx in the loop for integrating with cert-manager then TURN/UDP/DTLS will not work (unless you use a signed certificate with STUNner). We have cert-manager integration planned on the drawing board, but this will definitely come after v1. Plain TURN/UDP should work fine though. Note that the TURN payload will be encrypted anyway.
- Use TURN/TCP/TLS: nginx always creates conntrack state for TCP, so this option is known to work. Of curse, TCP is suboptimal for real-time traffic so this may have massive negative impact on latency/jitter.
from stunner.
I think doing some nginx magic should work, will try to do that and post my results, regardless of success/failure. For now just to test it I went with dropping nginx from the loop (just for webrtc traffic) so my setup looks as follows:
Note: ports 3478 for udp and 3479 for tcp as 'public' access is not a typo, but in iptables i redirect it to proper extIP:3478 ports from metalLB.
However i ended up worse than before (with nginx proxy for tcp/udp stunner purposes, ICE gathering was fine), now my ICE gathering is stuck, so im debugging it at the moment. I've also checked logs of tcp/udp gateways from stunner, but absolutely no logs are produced (before, when i used nginx proxy, i had some logs), so i guess my error must be somewhere before.
Stunner UDP/TCP gateways are "first" point of contact from stunner perspective?
from stunner.
You should lecture GitHub issue writing skills at a university...
Anyway, if there are no logs in stunnerd
that means that the traffic does not even hit the TURN server. I guess the problem is somewhere at the MetalLB part.
As per whether STUNner is a "first point of contact" I'd say it depends. There can be any number of L3/L4 middleboxes (firewalls, NATs, tunnel endpoints) between the client and the stunnerd
pods, TURN is designed to survive that. However, speaking of UDP, we often see MTU issues causing weird errors, so you'd better avoid extensive tunneling. Try testing with TCP: if TURN/TCP works then your setup is fine and the issue is a missing conntrack or an MTU issue somewhere on the client-to-stunnerd path.
from stunner.
Related Issues (20)
- Meetecho Janus integration HOT 7
- turn ERROR: Failed to handle datagram: failed to create stun message from packet: unexpected EOF: not enough bytes to read header HOT 1
- Mixed protocol available for AWS? If not how to setup health check if not supported? HOT 3
- Does it work with MediaMTX (Whip) and can I choose the destination server with an API? HOT 8
- Gatteway API v1.0 incompatibility on GKE HOT 6
- UDP Gateway Error HOT 11
- srflx ICE candidate wrong ip? HOT 1
- SRS integration? HOT 5
- Extra question about horizontally scaled Stunner HOT 3
- Example app udp-greeter.yaml not working - help needed HOT 10
- v0.16.0 - Websocket error HOT 3
- v0.16.0 - Stunnerd pods get into state where they won't respond to TURN requests HOT 1
- Allow Gateways to request a specific NodePort in the automatically created Service HOT 7
- TURN connection breaks when the backend pod enters graceful shutdown HOT 13
- `stunnerctl config` does not fall back to the default namespace
- Help testing on AKS (Azure) HOT 1
- Deployment in headless mode does not resolve public ip address of client HOT 4
- Turncat example not working on EKS HOT 11
- error install on container : kubernate and helm HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stunner.