Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: ensure app listens on IPv4/tcp ports #48

Merged
merged 1 commit into from
Sep 13, 2022
Merged

Conversation

LRTNZ
Copy link
Contributor

@LRTNZ LRTNZ commented Apr 22, 2020

Due to a change in the way the app dependency works, not specifying
an address (even just '0.0.0.0') means that the program would listen to
an IPv6 address/port, instead of IPv4, which nearly everything is still
configured for. This meant that the client could not see the media
scanner. This commit fixes that, by making the app dependency listen
on an IPv4 address/port.

Due to a change in the way the app dependency works, not specifying
an address (even just '0.0.0.0') means that the program would listen to
an IPv6 address/port, instead of IPv4, which nearly everything is still
configured for. This meant that the client could not see the media
scanner. This commit fixes that, by making the app dependency listen
on an IPv4 address/port.
@Julusian Julusian changed the title fix: Fixed app listening to IPv6/tcp6 ports instead of IPv4/tcp ports fix: ensure app listens on IPv4/tcp ports Sep 13, 2022
@Julusian Julusian merged commit 56c4670 into CasparCG:master Sep 13, 2022
Julusian added a commit that referenced this pull request Sep 4, 2023
@Julusian
Copy link
Member

Julusian commented Sep 4, 2023

I have reverted this in v1.1.1, as it breaks the default configuration on windows.
On windows localhost resolves to ::1 with a higher priority than 127.0.0.1, resulting in caspar attempting to connect to the scanner over ipv6, failing and then retrying over ipv4.

Additionaly, on both windows10 and ubuntu22.04, with this reverted I am able to access the scanner over both http://127.0.0.1:8000, http://[::1]:8000 in chrome, so it looks like they are both binding well enough to ipv4 and ipv4.
Perhaps this bind behaviour changed as part of the nodejs update? Or during an os update? Either way it looks to no longer be an issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants