Bug: Websocket won't start without IPv6 support

[Filiaes]

Operating System Info

Other

Other OS

6.5.7-arch1-1

OBS Studio Version

Other

OBS Studio Version (Other)

29.1.3 (64 bit)

obs-websocket Version

Git

OBS Studio Log URL

https://obsproject.com/logs/kg1WxufbMT6tq19g

OBS Studio Crash Log URL

No response

Expected Behavior

Related to #1131 websocket should work with the current obs version for linux.

Current Behavior

Websocket isn't starting if IPv6 isn't available for the system:

16:49:23.909: [obs-websocket] [WebSocketServer::Start] Not locked to IPv4 bindings
16:49:23.911: [obs-websocket] [WebSocketServer::Start] Listen failed: Address family not supported by protocol

Steps to Reproduce

• Install Arch
• Disable IPv6 support in kernel
• Install flatpak
• Install obs-studio flatpak version
• Start websocket

Anything else we should know?

When I start obs with --websocket_ipv4_only flag the websocket is starting. Anyway, the fix in 6434c42 won't work for the messages in my log.

[Gambloide]

I get the same error in my logs regardless of IPv6 being enabled or not on Windows 10 with OBS 30.0.0 64bit using the version of OBS Websocket shipped with OBS.

Background:
On the 12th Nov, after installing OBS 30.0.0 on Windows 10 I suddenly couldn't connect to obs websocket anymore.
As it was showing me only an IPv6 binding in the UI, I assumed that this was the cause and disabled IPv6 on my Ethernet connection altogether, rebooted my PC and it worked again.

The next time I went to connect to obs websocket (today), it wouldn't connect again. I checked the logs and saw this:

17:18:26.016: [obs-websocket] [obs_module_post_load] WebSocket server is enabled, starting...
17:18:26.016: [obs-websocket] [WebSocketServer::Start] Not locked to IPv4 bindings
17:18:26.016: [obs-websocket] [WebSocketServer::Start] Listen failed: Only one usage of each socket address (protocol/network address/port) is normally permitted.

This is with IPv6 disabled and without the --websocket_ipv4_only flag

So I went ahead and enabled IPv6 again, rebooted and I could connect ONCE (I have the System Tray alerts enabled and it showed an established connection). After restarting OBS it wouldn't let me connect again, so I unchecked Enable WebSocket server, hit Apply, checked it again and hit Apply again. Still no connection possible and the logs show the same error only with some extra lines before showing me changing the settings:

17:21:06.168: [obs-websocket] [SettingsDialog::SaveFormData] A setting was changed which requires a server restart.
17:21:06.168: [obs-websocket] [WebSocketServer::Stop] Call to Stop() but the server is not listening.
17:21:08.599: [obs-websocket] [SettingsDialog::SaveFormData] A setting was changed which requires a server restart.
17:21:08.599: [obs-websocket] [WebSocketServer::Stop] Call to Stop() but the server is not listening.
17:21:08.599: [obs-websocket] [WebSocketServer::Start] Not locked to IPv4 bindings
17:21:08.599: [obs-websocket] [WebSocketServer::Start] Listen failed: Only one usage of each socket address (protocol/network address/port) is normally permitted.

This is with IPv6 enabled and without the --websocket_ipv4_only flag

If I start OBS with --websocket_ipv4_only these are the logs, and it says it would bind to IPv4, but logs an IPv6 address and still shows an IPv6 address when clicking Show Connect Info in the UI:

17:35:34.805: [obs-websocket] [Config::Load] --websocket_ipv4_only passed. Binding only to IPv4 interfaces.
[...]
17:35:34.867: [obs-websocket] [obs_module_post_load] WebSocket server is enabled, starting...
17:35:34.867: [obs-websocket] [WebSocketServer::Start] Locked to IPv4 bindings
17:35:34.867: [obs-websocket] [WebSocketServer::ServerRunner] IO thread started.
17:35:34.869: [obs-websocket] [WebSocketServer::Start] Server started successfully on port 4455. Possible connect address: 2a02:2455:1854:9600:3581:1f43:4c69:f4ab

This is with IPv6 enabled but with the --websocket_ipv4_only flag provided

Only when I disabled IPv6 on my network interface AND threw --websocket_ipv4_only at OBS was it actually starting the websocket with an IPv4 binding:

17:39:36.737: [obs-websocket] [obs_module_post_load] WebSocket server is enabled, starting...
17:39:36.738: [obs-websocket] [WebSocketServer::Start] Locked to IPv4 bindings
17:39:36.738: [obs-websocket] [WebSocketServer::ServerRunner] IO thread started.
17:39:36.740: [obs-websocket] [WebSocketServer::Start] Server started successfully on port 4455. Possible connect address: 192.168.178.29

This is with IPv6 disabled and with the --websocket_ipv4_only flag provided

Funnily, I was still not able to connect again. So I replaced localhost with 127.0.0.1 in the connection address (from ws://127.0.0.1:4455 to ws://localhost:4455) and THEN it suddenly worked, which seems to imply that it was resolved to ::1.

To complete the cycle I removed the --websocket_ipv4_only flag again and enabled IPv6 again, but that simply resulted in this error in the logs again:

18:53:47.441: [obs-websocket] [obs_module_post_load] WebSocket server is enabled, starting...
18:53:47.441: [obs-websocket] [WebSocketServer::Start] Not locked to IPv4 bindings
18:53:47.441: [obs-websocket] [WebSocketServer::Start] Listen failed: Only one usage of each socket address (protocol/network address/port) is normally permitted.

This is with IPv6 disabled and without the --websocket_ipv4_only flag again

---

I do not know if a Windows update changed how localhost is resolved or something else interfered, but the general behavior I observed and the associated logs in regards to having IPv6 enabled/disabled and the --websocket_ipv4_only flag being present or not seems inconsistent.

[Gambloide]

My case might actually be explained by #1085

I will add further information there.

[tt2468]

The log you provided shows that the running obs-websocket version is 5.2.3, while the commit which implements the automatic ipv4 fallback was first introduced in 5.3.0: 6434c42

What method are you using to specify startup flags? I don't see how it could be still trying IPv6 unless the argument is not actually being passed to OBS.