m1k1o / neko

A self hosted virtual browser that runs in docker and uses WebRTC.
https://neko.m1k1o.net/
Apache License 2.0
5.94k stars 449 forks source link

Disconnected peer failed #146

Open trentwiles opened 2 years ago

trentwiles commented 2 years ago

(note, I've read over https://github.com/m1k1o/neko/issues/61 but haven't seemed to be able to fix the issue)

I'm running this on my PC (Ubuntu impish) to test it out before I put it on a VPS. I tried to sign into the control panel at localhost:8080 and I got the error "Disconnected peer failed". I'm running the default docker-compose file:

version: "3.4"
services:
  neko:
    image: "m1k1o/neko:firefox"
    restart: "unless-stopped"
    shm_size: "2gb"
    ports:
      - "8080:8080"
      - "52000-52100:52000-52100/udp"
    environment:
      NEKO_SCREEN: 1920x1080@30
      NEKO_PASSWORD: neko
      NEKO_PASSWORD_ADMIN: admin
      NEKO_EPR: 52000-52100
      NEKO_ICELITE: 1

My errors are as follows:

2022-02-23 17:32:40,007 DEBG 'neko' stdout output:
5:32PM INF ICE connection state changed: checking module=webrtc subsystem=pc
5:32PM INF connection state has changed connection_state=checking module=webrtc

2022-02-23 17:32:51,110 DEBG 'neko' stdout output:
5:32PM WRN read message error error="websocket: close 1005 (no status)" module=websocket

2022-02-23 17:32:51,111 DEBG 'neko' stdout output:
5:32PM INF Setting new connection state: Closed module=webrtc subsystem=ice
5:32PM INF peer connection state changed: closed module=webrtc subsystem=pc
5:32PM INF Pipelines shutting down... module=remote
5:32PM INF ICE connection state changed: closed module=webrtc subsystem=pc
5:32PM INF connection state has changed connection_state=closed module=webrtc
5:32PM INF peer closed id=y-ECKB0O7yDLAS0Mv1YaZLya0CgWw7j2 module=webrtc
5:32PM WRN Failed to start manager: connecting canceled by caller module=webrtc subsystem=pc

2022-02-23 17:32:51,111 DEBG 'neko' stdout output:
5:32PM WRN Failed to start SCTP: DTLS not established module=webrtc subsystem=pc
5:32PM WRN undeclaredMediaProcessor failed to open SrtpSession: the DTLS transport has not started yet module=webrtc subsystem=pc
5:32PM WRN undeclaredMediaProcessor failed to open SrtcpSession: the DTLS transport has not started yet module=webrtc subsystem=pc

2022-02-23 17:32:51,116 DEBG 'pulseaudio' stdout output:
D: [pulseaudio] source.c: auto_null.monitor: state: RUNNING -> IDLE

2022-02-23 17:32:51,117 DEBG 'pulseaudio' stdout output:
D: [pulseaudio] core.c: Hmm, no streams around, trying to vacuum.
I: [pulseaudio] source-output.c: Freeing output 2 "Record Stream"

2022-02-23 17:32:51,117 DEBG 'pulseaudio' stdout output:
I: [pulseaudio] client.c: Freed 2 "neko"
I: [pulseaudio] protocol-native.c: Connection died.
yesBad commented 2 years ago

try neko_icelite: 0 ? that's what I atleast use

trentwiles commented 2 years ago

I tried, I'm still getting the error:

neko_1  | 7:37PM WRN Failed to start manager: connecting canceled by caller module=webrtc subsystem=pc
neko_1  | 7:37PM WRN Failed to start SCTP: DTLS not established module=webrtc subsystem=pc
neko_1  | 7:37PM WRN undeclaredMediaProcessor failed to open SrtcpSession: the DTLS transport has not started yet module=webrtc subsystem=pc
neko_1  | 7:37PM WRN undeclaredMediaProcessor failed to open SrtpSession: the DTLS transport has not started yet module=webrtc subsystem=pc
neko_1  | 7:37PM INF peer closed id=_vcMKk7n5MwQbWDKV8gDUpNPO90ivES6 module=webrtc
m1k1o commented 2 years ago

Enabling icelite assumes, that your ports are reachable from outside. What should always be the case, that's why it is the prefered and default configuration. If you set it to 0, then your configuration is more resillient to network connecting. E.G. you can have NAT in betwen but in that case you should use own TURN-servers, to have this flexibility or open ports on the client. Otherwise there is not much difference between them.

Have you gone trough the troubleshooting guide:

stautonico commented 1 year ago

I'm having the same issue, locally, I can connect to it no problem, but remotely, no luck. I'm running it behind a reverse proxy with nginx

jgmoss commented 1 year ago

Setting NEKO_NAT1TO1 solved the problem for me.

vgdh commented 1 year ago

You need to add your IP address that you will use to connect to Like that:

version: "3.4"
services:
  neko:
    image: "m1k1o/neko:firefox"
    restart: "unless-stopped"
    shm_size: "2gb"
    ports:
      - "8080:8080"
      - "52000-52100:52000-52100/udp"
    environment:
      NEKO_SCREEN: 1024×576@30
      NEKO_PASSWORD: neko
      NEKO_PASSWORD_ADMIN: admin
      NEKO_EPR: 52000-52100
      NEKO_ICELITE: 1
      NEKO_NAT1TO1: 192.168.1.106
Healzangels commented 1 year ago

@vgdh you won't also happen to be using Nginx for reverse proxy? My setup works locally however whenever someone attempts to access remotely I see Disconnected peer failed. @stautonico were you able to sort this? Did confirm I have the NEKO_NAT1TO1: set to Private IP of host running Neko.

stautonico commented 1 year ago

I haven't touched this in a long time. I couldn't get it to work through an Nginx reverse proxy, since the proxy doesn't pass websockets. I couldn't get websockets working, but it might be possible, but I don't know enough about nginx. Ik this isn't the solution for everyone, but to get it working, I just added my friends to my home wireguard VPN, so they can connect "locally" over the vpn.

vgdh commented 1 year ago

@vgdh you won't also happen to be using Nginx for reverse proxy? My setup works locally however whenever someone attempts to access remotely I see Disconnected peer failed.

No I didn't use nginx. Just simple access through my home local network

m1k1o commented 1 year ago

@Healzangels

Did confirm I have the NEKO_NAT1TO1: set to Private IP of host running Neko.

NEKO_NAT1TO1 needs to be IP that you clients can reach. If you set it to private and your clients cannot reach that, then they cannot connect. It needs to be public IP with ports forwarded correctly.

Healzangels commented 1 year ago

Thanks for the follow up! Is this still the case using Cloudflare tunnel/Reverse proxy?

I have got to a point where locally everything works great. Remotely I can connect to my neko reverse proxied site. neko.example.com and enter my login credentials. Entering the wrong creditable are denied, correct get the green circle which ends up presenting the Disconnected peer failed.

Within the console the error is presented as: WebRTC: ICE Failed, add a TURN server and see about:webtrc for more details.

Additional details: Running in Docker on Bridge Network.

I've tried entering my Public IP address for NEKO_NAT1TO1 plus opening the WebUI TCP port on my local firewall with pointing to my local Unraid ip + Webui port

m1k1o commented 1 year ago

Is this still the case using Cloudflare tunnel/Reverse proxy?

UI and WebRTC are separated. You can put UI behind reverse proxy, thorugh tunnel, anywhere. It's just HTTP(s).

WebRTC: ICE Failed, add a TURN server and see about:webtrc for more details.

This means that neko does not have connectivity to the server. There is troubleshooting guide.

I've tried entering my Public IP address for NEKO_NAT1TO1 plus opening the WebUI TCP port on my local firewall with pointing to my local Unraid ip + Webui port

Try opening either EPR range, TCP andd/or UDP mux ports, depending on what you use.

For WebRTC there is either NEKO_EPR=56000-56100 where 56000-56100 is the range for UDP ports. Every client is allocated one port. Alternatively, NEKO_TCPMUX=8081 and/or NEKO_UDPMUX=8082 where you need only those two ports to be reachable from clients. See more info in docs.

Please note, WebRTC traffic is not HTTP traffic so it cannot be but behind reverse proxy. But it can be realyed using TURN if you don't want to expose those ports. But that means, you need to have somewhere TURN server.

Healzangels commented 1 year ago

Thanks for the links and the additional information! Was able to get everything working with making changes to open ports + TCMUX/UDP Ports.

hari-ultiweb commented 2 months ago

NEKO_NAT1TO1: 192.168.1.106

This perfectly solved the error. Incase if for some reason this doesn't work, replace the IP by 127.0.0.1 and it should work for sure. Here is a snippet for reference

environment:
      NEKO_SCREEN: "1920x1080@60"
      NEKO_PASSWORD: ultiweb
      NEKO_PASSWORD_ADMIN: ULTIweb
      NEKO_EPR: 45800-45900
      NEKO_FILE_TRANSFER_ENABLED: "true"
      NEKO_ICELITE: 1
      NEKO_DEBUG: 1
      NEKO_NAT1TO1: 127.0.0.1