Option to bind Sunshine to a specific network interface?

[Fliesenmeister]

Select Topic Area

Question

Body

Hey,
I noticed that when I have multiple LAN interfaces on my host, clients sometimes connect via the wrong one. Is there a way to tell Sunshine which network interface or IP to use for streaming?

If there’s already an option for that, I probably missed it – sorry in that case! But if not, I’d love to help add something like a bind_address setting.

[ReenigneArcher]

I'm not sure if this is allowed yet. Can you try the external_ip option and let me know if that works?

[ReenigneArcher]

I don't recall seeing any PR yet.

[Fliesenmeister]

Hi, no sorry, I haven’t managed to implement it so far. I don’t have enough know-how, so I’m using the workaround of forcing Sunshine to a LAN adapter via the Windows Firewall.

[ReenigneArcher]

I added this to our roadmap: LizardByte/roadmap#127

[ajj]

OK - I've taken a look and most of the work seems to be in UI / config to enable host_create() to either use a specific address or use the call to af_to_any_address_string() if we want the default behaviour. Will need to handle IP v4 and v6 options.

I'll put some effort into this over the next 2-3 months.

[ajj]

Thanks for the rapid work @ReenigneArcher - I just dropped in to say that I was making progress, and here we are with a working solution!

[locke-chappel]

Just wanted to chime in - Being able to bind the service(s) to a specific IP might also provide a functional work-around (at least for my use case) for #3569.

With respect that issue - I don't mind using host mode networking in the container if I can bind all services to a specific IP (this would then allow multiple instances per host again - right now it binds to all interfaces which forces a single sunshine instance per host). Being able to use host mode networking then evades the issues with udev inputs so enabling specific IP bindings should provide a path to multi-seat hosting via containers.

That being said, I don't normally use host mode networking for containers so I'm not sure if there are other interesting interactions that may be an issue but this feature is promising.

[ReenigneArcher]

I have a PR open here to add this feature.

PR: LizardByte/Sunshine#4481
artifacts: https://github.com/LizardByte/Sunshine/actions/runs/20042552727?pr=4481#artifacts

Please test and let me know if it works for you.

[locke-chappel]

The binding issue is fixed. I was able to run two instances in two containers in parallel. netstat shows all ports listed in the Sunshine UI as being bound to their respective instances.

I'm seeing some other weirdness that may or may not be related to these changes.

1. Sunshine seems to be emitting a Warning: Unable to find MAC address for <bound ip> unless a client is connected. Upon client connection this warning stops but then resumes once the client disconnects. Shows up about once a second in the logs.

2. This could be an issue with my deployments but when I connected two clients to each of the sunshine instances I saw that the video feed was the same for both. I verified that each client instance was indeed connecting to their own sunshine instance and given that netstat claims all ports are bound the proper IPs I suspect the issue is some sort of shared memory issue - quit likely due to my host environment but could also be a hidden side-effect as Sunshine was never intended for parallel discrete instances on a single host. :) Still seems worth mentioning. In my case I am using an old pascal GPU and under nvidia-smi I see two copies of Sunshine each with the expected memory allocation for the stream resolution - suggesting there are two discrete instances encoding but I also only saw one instance of XOrg and xfwm4 which makes me think my containers are sharing memory they shouldn't and thus probably not a Sunshine issue.

In any case, under docker with host mode networking, Debian OS (both host and container) it appears that the IP binding is working. I can't speak for Windows/MacOS so take my testing for what it's worth. :)

Thank you for your work on this. One step closer to a multi-seated "LAN party in a box" project I am tinkering with. :)

[locke-chappel]

I think I might have a plausible explanation for the MAC address warning. In my docker based setup the host uses IP aliases to bind multiple IPs to the same NIC. It's possible that instead of interpreting the IP alias' MAC as being the bound physical MAC that it instead is viewed as having no MAC.

In order to debug some other unrelated issues in my use case I am building a test VM to rule out the containerization layer and I noticed in this VM since I assigned two NIC each with unique MAC address I do not see the MAC warning when running both instances of Sunshine on this VM.

Anyway, I'm not sure why the MAC is needed and if not having it causes any issues but it looks like IP aliases may not be fully compatible (which is fine, I can assign multiple NICs to my docker hosts if it comes that, IP aliases were just a convenient way to configure the host, not a requirement.) If it turns out having the MAC is important it may be useful to make note of this somewhere in case it comes up again. :)

[ReenigneArcher]

I am not sure exactly how moonlight uses the mac address, but we only provide it for paired clients.

    // Only include the MAC address for requests sent from paired clients over HTTPS.
    // For HTTP requests, use a placeholder MAC address that Moonlight knows to ignore.
    if constexpr (std::is_same_v<SunshineHTTPS, T>) {
      tree.put("root.mac", platf::get_mac_address(net::addr_to_normalized_string(local_endpoint.address())));
    } else {
      tree.put("root.mac", "00:00:00:00:00:00");
    }

[jglamine]

I've been using this on MacOS Tahoe for a few days. It appears to work, although I haven't done extensive testing. I'm just binding to 127.0.0.1, then tunneling that traffic elsewhere using rathole.

[ajj]

Tested on Linux (Debian Trixie and Linux Mint 22.1) and it works for my use case of avoiding the bandwidth conflict issue when a >1Gbe connection is present.