mirror of
https://github.com/games-on-whales/wolf.git
synced 2026-10-15 21:12:08 +00:00
[GH-ISSUE #265] Multiple users from a single IP unable to connect #183
Labels
No labels
🧠 1 - 🤖 999
AMD
bug
bug
cannot reproduce
documentation
duplicate
easy
enhancement
enhancement
enhancement
fixed?
fixed?
good first issue
hard
help wanted
Intel
invalid
LXC
medium
moonlight-protocol
Multi GPU
nixos
not a bug
nvidia
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
games-on-whales/wolf#183
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Greaper88 on GitHub (Oct 10, 2025).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/265
I've got a "morale server" setup at home for myself and my coworkers so we can do something fun on slow shifts. Unfortunately, only one connection can be established, and it seems to be because all users appear to be coming from the same IP. I know my internet and the server can handle more than one user (using phones on mobile networks to add other connections). Is this a bug or issue with how Moonshine communicates with Wolf?
@ABeltramo commented on GitHub (Oct 10, 2025):
How are you connecting to Wolf? Is it via a Proxy or by opening the required ports to WAN?
We strongly suggest to use more secure options like OpenVPN, Wireguard or Tailscale instead. Not only it'll fix all the issues that you are experiencing but it'll also add encryption and authentication for free 😉
@Greaper88 commented on GitHub (Oct 11, 2025):
Required ports are open to WAN. On our PCs, we're using Moonlight portable. This is pretty much our only option as installing programs isn't really a thing on work laptops... And even if there are portable options for these VPNs, I don't want all the internet traffic trying to go through my node at home. VPNs also usually introduce issues that would result in the local resources at work being unusable.
@ABeltramo commented on GitHub (Oct 11, 2025):
I would need the full Wolf logs of a failed run to get a better sense of what's going on, possibly with the env variable
WOLF_LOG_LEVEL=DEBUG. You can get them simply viaThat is exactly what Tailscale does btw, it'll only connect to the LAN IPs when accessing them. All the rest of the traffic flows normally. But I get the point that you can't install any additional SW.
@Greaper88 commented on GitHub (Oct 12, 2025):
So, I connected my phone to the WiFi for this, even the guest WiFi goes through the same router as the work network, so both devices appear to come from the same IP address. I connect from my desktop, let it get into something, such as steam, then attempt to connect from my phone. My phone will kick me back with errors about making sure I've forwarded the proper ports, the desktop continues without issue. I change my phone to 5G, and try again. It manages to connect. The log for the failed attempt is below:
another possibly relevant section of log:
There are pages of
wolf-1 | EVP_DecryptFinal_ex failedint he logs....@Greaper88 commented on GitHub (Oct 12, 2025):
As a side note, System specs:
@ABeltramo commented on GitHub (Oct 12, 2025):
I can't get a clear picture just by looking at those few log lines, please post the full Wolf logs from the start. It seems that you might have different issues going on at the same time..
@Greaper88 commented on GitHub (Oct 12, 2025):
Ok, so I've added the debug switch to the environment, and have Ctrl-H -- replace-all'd the IP addresses for my work (there was only one). I restarted the container, logged in from my desktop and let Steam load. Once Steam loaded, I connected from my phone over the guest Wi-Fi at work. I attempted to load Steam and got kicked back with a no video received from the host error. I then connected to my mobile data, which is only 4G where I'm at, and reconnected. I was able to successfully connect from there. Any other IPs in the logs are either my mobile IP which changes regularly, or are internal IPs.
@ABeltramo commented on GitHub (Oct 12, 2025):
So the
EGL_NOT_INITIALIZED erroris a known issue with Nvidia which I'm working on here. Basically when any of the running sessions closes it'll cause issues to other running pipelines. You can side-step it with the env variableWOLF_USE_ZERO_COPY=FALSE(which will result in slightly worst performances).I don't see the
[RTSP] error parsing messagethat were present in the earlier log though..@Greaper88 commented on GitHub (Oct 12, 2025):
I was having really weird issues the last night, which may have been due one our ISPs being unreliable... LOL. Ah ok. I do know there are session limits on GeForce cards, which is why I got myself a Quadro card as there are no (or at least no significant) artificial session limits on them.
@ABeltramo commented on GitHub (Oct 12, 2025):
That's not it, it's unfortunately a bug specific to how we (try to) achieve a highly efficient video encoding pipeline only on Nvidia. I have a fix working, just need to iron out a few small things.. Try out running it with
WOLF_USE_ZERO_COPY=FALSEand see if you can connect with multiple users; if that works we can then deal with the loss of performance.@Greaper88 commented on GitHub (Oct 12, 2025):
I'm back to having weird issues and random disconnects... I'm going to setup a subnet at home and see if I can reproduce the issue in a more controlled environment. Connecting through the subnet will make all connections come from the subnet router's IP, which is as close to a real-world scenario as I can get. Here are the logs I have. I can't get anything to connect.
and as for that environment variable after adding it to my docker compose file:
@ABeltramo commented on GitHub (Oct 12, 2025):
That's a new one
Which Nvidia driver and CUDA version do you have installed? I wonder if this is something specific to the Quadro RTX 4000 card..
@Greaper88 commented on GitHub (Oct 12, 2025):
I'm using the newer drivers that update often, not the long term drivers (I forget the terms), I'm also using the proprietary driver, not the open driver.
@ABeltramo commented on GitHub (Oct 12, 2025):
I've seen some issues with the recently released CUDA 13 and Gstreamer, would it be possible for you to revert to CUDA 12.x? Which OS are you running on the host?
@Greaper88 commented on GitHub (Oct 12, 2025):
As for reverting, lemme see. I just hope that my Jellyfin server can use Cuda 12.... (it should)
edit: this will be awhile, I have to restart the machine, but I'm NOT doing that until the backup of this degraded RAID array is complete. Will report back once that's all done.
@Greaper88 commented on GitHub (Oct 17, 2025):
So, I've attempted to install cuda-toolkit 12.9 after purging v13. It's cause more problems as a whole. I actually had my video driver crash and hang the system. For some reason, nvidia-smi still lists cuda 13 as the version isntalled. I may just be stuck with 13.
@ABeltramo commented on GitHub (Oct 17, 2025):
@Greaper88 thanks for trying! I'm working on a bunch of fixes for Nvidia and I'll make sure to also bundle the upstream fixes from Gstreamer for Cuda 13. I'll ping you once I've got something ready to be tested!
@Greaper88 commented on GitHub (Oct 17, 2025):
Sweet. I'm willing to try beta builds too, just need to know what image to tell my compose file to pull. Thank you very much for this.
@Greaper88 commented on GitHub (Oct 24, 2025):
I can now get multiple users to connect. The issue is at least somewhat resolved. However, I do have to restart Wolf when someone else leaves because I then get hit with a "poor network performance" error.
@Greaper88 commented on GitHub (Oct 25, 2025):
So, I started the server. We both started to connect to XFCE around the same time, although I clicked first. We both load in. He disconnected from his session, and was able to reconnect without issues. I then left my session, but was unable to start anything, receiving either a network performance low error or a no video received from host error in the moonlight client. This appears to be the same thing that we had hapopen when we first tried Steam after I pulled the update.
@Greaper88 commented on GitHub (Oct 25, 2025):
So, attempting to connect with a third device also results in that device being hit with the same issue. So it seems to work until a stream is ended, and then no streams are allowed to be created. Seems to be the issue I saw somewhere with Wayland. Will attempt to verify with three devices, and report back.
@Greaper88 commented on GitHub (Oct 25, 2025):
Well, looks like the same error actually. When the second device connected to XFCE, the video feed on the first device froze, forcing it to need to be exited. Attempting to reconnect to the session results in this happening.
@Greaper88 commented on GitHub (Oct 28, 2025):
Posting an update on how I replicated this issue:
I have an extra router just Lying around. I connected to this router to my network, and connected two devices to it. This is a physical subnet. This means that any clients from said subnet will have the same IP address. Connect one device to the Wolf server, load into an app (Wolf-UI in my case since I'm giving the beta Wolf image a try), and then connect from the second device on the subnet. Attempting to connect this second device will result in receiving no video from the host. The log appears to be consistent with my issue with myself an my coworker not being able to connect from work.
@Moscalu commented on GitHub (Apr 4, 2026):
Facing the exact same error:
I'm trying to connect using wireguard vpn. Cannot get the session work simultaneously.
@Moscalu commented on GitHub (Apr 5, 2026):
I my case the problem was because the wireguard was configured with masquerrade(NAT) and all my clients were accessing the gow wolf server from the same ip address.
But the approach of @Greaper88 is interesting. I would like to see an solution to his problem.
@Greaper88 commented on GitHub (Apr 5, 2026):
I'm currently running multiple instances of moonligh-web using separate docker composes. This allows each instance to have its own IP when it hits the Wolf server.
@r0b0tb4c0n commented on GitHub (Sep 17, 2026):
i ran into this same problem yesterday, the core of the issue is in your log here:
wolf-1 | 14:02:55.624926201 DEBUG | [RTSP] found session by matching IP: 192.168.1.175
when you connect, wolf is keying off of the IP address from the source, if you have multiple systems connecting from the same ip it seems to get confused and sends the stream to the wrong host. the only way to fix it when you get to that state is to restart the wolf container.
as a super hacky work around (that i've only tested to work for local network connections) i did the following:
so what happens is:
192.168.1.100 -> 192.168.1.221 -> source ip gets changed to 192.168.1.60 -> traffic is then passed into wolf
192.168.1.100 -> 192.168.1.222 -> source ip gets changed to 192.168.1.61 -> traffic is then passed into wolf
because the "source" ip addresses are different, i don't get the collision causing stream failures
then on the way out the firewall sees that traffic and re-addresses the destination so that it will come back to the proper moonlight client.
the ip's i used (60 and 61) are not in my dhcp range and are not assigned to anything so i don't run into issues with duplicate ip's/arp issues.
@Greaper88 commented on GitHub (Sep 20, 2026):
I've got a partial fix for this issue here https://github.com/Greaper88/wolf/tree/dev-shared-ip-sessions
If it can't figure out who a client is, it'll actually reject them cleanly without putting the server into an awkward state.
It may be unable to reconnect a user if they try to resume their stream, but this can be worked around by changing just about any of the video stream settings in the client.
The image is
ghcr.io/greaper88/wolf:dev-shared-ip-sessionsand is based off of the master repo as of commit2273b2e@r0b0tb4c0n commented on GitHub (Sep 20, 2026):
awesome! i'll start testing it tomorrow and let you know what i hit
@r0b0tb4c0n commented on GitHub (Sep 20, 2026):
it doesn't seem to want to let me pair:
i just barely have enough time to copy the link and paste it into my browser before it spits out another pairing url.
@Greaper88 commented on GitHub (Sep 20, 2026):
hmm.... i just used my previous config.toml file, so my users were already paired. No changes were made directly to the pairing code.
Also, you can usually just hold Ctrl and click on the link in the terminal.
Few questions:
@Greaper88 commented on GitHub (Sep 20, 2026):
I was able to successfully pair a new client with no issues. (Public-facing IP redacted)