listen on both ipv4 and ipv6

[aptalca]

closes #178

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/code-server/4.23.1-pkg-4284c89d-dev-79293112331036168cc4031bfe7c961af30d0498-pr-179/index.html
https://ci-tests.linuxserver.io/lspipepr/code-server/4.23.1-pkg-4284c89d-dev-79293112331036168cc4031bfe7c961af30d0498-pr-179/shellcheck-result.xml

Tag	Passed
amd64-4.23.1-pkg-4284c89d-dev-79293112331036168cc4031bfe7c961af30d0498-pr-179	✅
arm64v8-4.23.1-pkg-4284c89d-dev-79293112331036168cc4031bfe7c961af30d0498-pr-179	❌

[thespad]

Is this going to suddenly break a bunch of users who've explicitly disabled IPv6?

[aptalca]

No idea. It needs to be tested.

I'm surprised that even though we're telling it to listen on ipv6, it also listens on ipv4 but I couldn't find any documentation. Just github issue discussions.

[thespad]

Well that's just weird:

# netstat -ntlp
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp6       0      0 :::8443                 :::*                    LISTEN      -   

$  docker ps | grep code
30ff101cac53   lspipepr/code-server:4.23.1-pkg-4284c89d-dev-79293112331036168cc4031bfe7c961af30d0498-pr-179   "/init"                  3 seconds ago   Up 3 seconds           0.0.0.0:8123->8443/tcp, :::8123->8443/tcp   

And both

curl -4 -sL http://localhost:8123

And

curl -6 -sL http://localhost:8123

Work. They also work inside the container so it's not just the docker NAT layer doing something odd.

[thespad]

TIL https://www.rfc-editor.org/rfc/rfc3493#section-3.7

Applications may use AF_INET6 sockets to open TCP connections to IPv4
nodes, or send UDP packets to IPv4 nodes, by simply encoding the
destination's IPv4 address as an IPv4-mapped IPv6 address, and
passing that address, within a sockaddr_in6 structure, in the
connect() or sendto() call. When applications use AF_INET6 sockets
to accept TCP connections from IPv4 nodes, or receive UDP packets
from IPv4 nodes, the system returns the peer's address to the
application in the accept(), recvfrom(), or getpeername() call using
a sockaddr_in6 structure encoded this way.

Also https://www.rfc-editor.org/rfc/rfc3493#section-5.3

As stated in section <3.7 Compatibility with IPv4 Nodes>,
AF_INET6 sockets may be used for both IPv4 and IPv6 communications.
Some applications may want to restrict their use of an AF_INET6
socket to IPv6 communications only. For these applications the
IPV6_V6ONLY socket option is defined.

But that will still break with IPv4-only network stacks for obvious reasons.

[miyurusankalpa]

@thespad It will break on users who have disabled IPv6 on the kernel level, others will have no issues. Those who have will aware of the issues with messing with the default kernel values.

As IPv6 only servers are becoming common, having a middle ground is the better option.

It will be better to have a DISABLE IPv6 option for such users, as it done on the kasmvnc image.

https://github.com/linuxserver/docker-baseimage-kasmvnc/blob/master/root/etc/s6-overlay/s6-rc.d/init-nginx/run#L29

[drizuid]

Is this going to suddenly break a bunch of users who've explicitly disabled IPv6?

hopefully, maybe it'll teach them to stop doing silly things left over from 2004

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/code-server/4.89.1-pkg-2e2dbd2e-dev-43762e8d1a1bb73155a207732b808ca9c656e210-pr-179/index.html
https://ci-tests.linuxserver.io/lspipepr/code-server/4.89.1-pkg-2e2dbd2e-dev-43762e8d1a1bb73155a207732b808ca9c656e210-pr-179/shellcheck-result.xml

Tag	Passed
amd64-4.89.1-pkg-2e2dbd2e-dev-43762e8d1a1bb73155a207732b808ca9c656e210-pr-179	✅
arm64v8-4.89.1-pkg-2e2dbd2e-dev-43762e8d1a1bb73155a207732b808ca9c656e210-pr-179	❌

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/code-server/4.90.2-pkg-ec2f2738-dev-6c3977dd4e90cacbac808c7c46de0104cdf7ea5f-pr-179/index.html
https://ci-tests.linuxserver.io/lspipepr/code-server/4.90.2-pkg-ec2f2738-dev-6c3977dd4e90cacbac808c7c46de0104cdf7ea5f-pr-179/shellcheck-result.xml

Tag	Passed
amd64-4.90.2-pkg-ec2f2738-dev-6c3977dd4e90cacbac808c7c46de0104cdf7ea5f-pr-179	✅
arm64v8-4.90.2-pkg-ec2f2738-dev-6c3977dd4e90cacbac808c7c46de0104cdf7ea5f-pr-179	✅

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/code-server/4.91.0-pkg-a6b2b800-dev-17b95b0ba62f66e6b818a6d5f7d4e1f17a6312a9-pr-179/index.html
https://ci-tests.linuxserver.io/lspipepr/code-server/4.91.0-pkg-a6b2b800-dev-17b95b0ba62f66e6b818a6d5f7d4e1f17a6312a9-pr-179/shellcheck-result.xml

Tag	Passed
amd64-4.91.0-pkg-a6b2b800-dev-17b95b0ba62f66e6b818a6d5f7d4e1f17a6312a9-pr-179	✅
arm64v8-4.91.0-pkg-a6b2b800-dev-17b95b0ba62f66e6b818a6d5f7d4e1f17a6312a9-pr-179	✅

[LinuxServer-CI]

I am a bot, here are the test results for this PR:
https://ci-tests.linuxserver.io/lspipepr/code-server/4.91.1-pkg-ab8f4cb9-dev-7655e6e780d64c3c870568720211f53b4cb5814c-pr-179/index.html
https://ci-tests.linuxserver.io/lspipepr/code-server/4.91.1-pkg-ab8f4cb9-dev-7655e6e780d64c3c870568720211f53b4cb5814c-pr-179/shellcheck-result.xml

Tag	Passed
amd64-4.91.1-pkg-ab8f4cb9-dev-7655e6e780d64c3c870568720211f53b4cb5814c-pr-179	✅
arm64v8-4.91.1-pkg-ab8f4cb9-dev-7655e6e780d64c3c870568720211f53b4cb5814c-pr-179	✅

[LinuxServer-CI]

This pull request has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[EricSeastrand]

This feature would help me. I'm embracing v6 everywhere on my network and would love to have Code Server along for the ride.

[EricSeastrand]

Sorry for the dumb question, but how can I help test this updated image? Do I just point my docker compose file to this version? amd64-4.91.1-pkg-ab8f4cb9-dev-7655e6e780d64c3c870568720211f53b4cb5814c-pr-179

I still have a few v4-only hosts in my network. Curious to see what breaks.

[thespad]

amd64-4.91.1-pkg-ab8f4cb9-dev-7655e6e780d64c3c870568720211f53b4cb5814c-pr-179

Yes, that's the image tag for the PR build

[LinuxServer-CI]

This pull request has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[tibeer]

Let's keep this open :)

[LinuxServer-CI]

This pull request has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[tibeer]

Not stale :)

[LinuxServer-CI]

This pull request has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.

[tibeer]

Not stale

[drizuid]

Not stale

seems pretty stale, not a single user requesting this has reported back anything from the pr build. We just have one random user spamming "not stale" every so often rather than testing and confirming anything...

[tibeer]

Pardon, but I am using this branch in production. It is working for me and I am really looking forward to get this into upstream without the need for me to build the images on my own. What else can I do to help here to get this over the finish line?

[j0nnymoe]

That may be, but we aren't to know you've been using this unless we get feedback from users testing it.

By testing it, I mean by using the pr image: amd64-4.91.1-pkg-ab8f4cb9-dev-7655e6e780d64c3c870568720211f53b4cb5814c-pr-179

[miyurusankalpa]

I don't think anyone in this thread have use case with IPv6 completely disabled or a host to test it.

my idea is let merge this and if there are issues lets add a DISABLE_IPV6 option as other images have handled it.

https://github.com/linuxserver/docker-baseimage-kasmvnc/blob/master/root/etc/s6-overlay/s6-rc.d/init-nginx/run#L29

[drizuid]

my idea is let merge this and if there are issues

lol, no. we are not going to yolo merge something without thorough testing..

[EricSeastrand]

Apologies for the delay reporting back. From my testing, I am fairly confident this won't break the core functionality of code server, even for those on v4-only hosts.
I tested with a host where v6 is completely disabled via sysctl and this change didn't break v4 for me. The incoming connections appear as v4-mapped addresses in the logs.
Support for v4 mapping has existed for over a decade as evidenced by this StackExchange question. Docker doesn't even support kernels older than 3.10, so it's hard to imagine anyone trying to run this image on a host that doesn't support v4 mapping.
I suppose there could be niche things like VSCode extensions that are not yet equipped to handle the way these "mapped" addresses look (ip whitelisting maybe?), but everything I use day-to-day seems to work fine.

Here's a screenshot of my test - a fresh instance of codeserver on a Debian 12 VM.

[tibeer]

@drizuid I created two VMs for testing. You can access them with username "ubuntu" via SSH:
node0.tibeer.de (IPv4 only)
node1.tibeer.de (IPv6 only)

code-server is installed on both VMs, while both of them are started on "[::]:80".
Of course, there is no SSL, so you might need to access the installation on a private browser tab. The password is saved in the home directory of the ubuntu user in a password.txt.

I hope this helps :)

[drizuid]

@thespad #179 (comment) thoughts?