Closed Penagwin closed 4 years ago
have you opened the ports on your system? (ufw maybe?) this is a tough one cause I cant reproduce it. How are you accessing the site? is it through the docker ip, localhost or your public ip?
The docker instance is running on a separate linux box on my network, and I'm connecting through it's local ip address. It's possible that the network firewall is blocking something (I don't control that here), but I have no custom ufw rules on that box.
May I recommend you keep this issue open, as I have a feeling some others will run into a similar issue.
if its working on firefox and not chrome, then the ports are correct. I did notice something,
WRN could not get server reflexive address udp6 stun:stun.l.google.com:19302
its warning something about udp6, and I believe this means its trying to use ipv6 to create a peer connection, check and see if you have any ipv6 rules in your firewall blocking the connection.
go here https://test.webrtc.org/ and tell me if ipv6 is enabled for you, try running that in the browser too
Might be on to something there. Maybe Chrome is trying for ipv6 only? Is there a way to force it to try over ipv4?
I'm not sure, I haven't used ipv6 before.
not sure what is causing this issue, if anyone has any suggestions?
Everything was working fine for me previously, but I am now encountering this error as well. Tried with both the Firefox and Chrome images. I can connect on Firefox but not type (possibly due to the clipboard), and on Chrome sometimes I am able to log in but I am unable to see anything.
edit: server logs, and client logs
(Chrome on MacOS, but same behaviour on Windows)
@sad To your knowledge, does the network you're using normally support ipv6 (comcast for example)? And does your computer have an ipv6 address regardless of the question above (You can check by using ifconfig
, ipconfig
, or ip addr
depending on your system).
For me my laptop had an ipv6 address, but the network I'm on doesn't really support ipv6, so I can't connect over the internet over ipv6.
I think what's happening is your computer has an ipv6 address so the browsers try to use that and fail. Likely we need to somehow force it to use ipv4?
EDIT: Also what's the output of test.webrtc.org (You can skip the audio/video test)
My ISP has never supported ipv6, but I was able to run neko pretty smoothly up until the other day over an ipv4 connection.
I've found a way to kinda debug this, add -e PION_LOG_TRACE='all'
when you run the docker container and view chrome://webrtc-internals
, if you can post the logs from this and we can see whats up with the connection
With PION_LOG_TRACE='all'
, here are my server logs. After about 4 or 5 retrys, I was able to connect and join the room, but I got no video. Client logs here.
Here is the data from chrome://webrtc-internals
, I'm not entirely sure how I should format this so if you would like I can take a screenshot instead. Hope this proves useful, thanks.
I should also add that I too tried with network_mode: "host"
and it made no difference.
edit: okay so I used this site, and got the following:
The server stun:stun.l.google.com:19302 returned an error with code=701:
STUN allocate request timed out.
I double checked and this appears to be the same ICE server that neko uses. There seems to be a few issues open about this server and Chrome, such as this one and this one. Seems like this could be the issue.
@Penagwin do you think you could verify that this is the same on your end?
@sad good research, thanks for posting the logs :D I'm going to keep digging and see if I can come up with something.
@sad good research, thanks for posting the logs :D I'm going to keep digging and see if I can come up with something.
Looking forward to it as I'm a big fan of this project! Thanks for all your hard work. If there's anything further I can do (including testing), just let me know. You can also reach me at reid#0001
on Discord.
@nurdism One thing you could do is run Neko in ICE Lite
mode. ICE Lite is a less complicated setup, and basically just has the server do a pong
instead of doing all the ICE logic.
By default Pion is a full ICE Agent, great if you have two peers behind NATs. However since Neko is always directly accessible (since you need that for HTTP) traffic, would I try doing this mode! Then you can also drop the STUN server from Neko.
You can enable ICE Lite here then have users set the IP address that neko is accessible at via this
You need to do ^ because the server doesn't have a way to find out its public IP by default. Maybe you could add something on Neko that goes and fetches the Public IP (and then calls SetNAT1To1IPs)
@Sean-Der thank you so much for looking into this.
ok so I have changed to ICE Lite and did some testing and it seems to work, I've pushed the containers to docker hub. Test them out, if you're still having issues try clearing your cache, if you're using cloud flair clear the cache on cloud flair's side too
ok so I have changed to ICE Lite and did some testing and it seems to work, I've pushed the containers to docker hub. Test them out, if you're still having issues try clearing your cache, if you're using cloud flair clear the cache on cloud flair's side too
All fixed for me, thank you.
awesomeness @Penagwin @danielpmc @xiya233 can you try the new version and see if this is working for you, I'll keep this open for a few days if no reply.
That is awesome, nice work @nurdism getting that in so fast! Such an amazing project, and you are closing out issues so quickly I wish I was as effective :)
I'm going to close this issue now, if this still continues to be an issue open a new issue and we'll continue from there.
Describe the bug The latest release coupled with the extra port range seems to have fixed my connectivity problems from firefox, however I still can't get it to work from Chrome.
The image is running on a linux box, and I'm testing from a mac on the same network.
I was able to get it to work in chrome by adding
--net=host
, and this error makes me think that there's a port range that might need to be forwarded or something? I'm not sure.To Reproduce Steps to reproduce the behavior:
docker pull nurdism/neko:latest
docker run -p 8080:8080 -p 59000-59100:59000-59100/udp -e NEKO_PASSWORD='secret' -e NEKO_ADMIN='secret' --shm-size=1gb nurdism/neko:latest
Client Log:![image](https://user-images.githubusercontent.com/1349689/73388963-308df900-42a1-11ea-885f-c759dd602021.png)
Server Log: