On Debian 12 VM with IPv6 disabled, hbbs listens on IPv6 sockets, and does not listen on IPv4

deekerman commented

2026-02-21 00:22:50 -05:00

Owner

Originally created by @bc-109 on GitHub (Feb 5, 2024).

Bug Description

On Debian machine with only IPv4 enabled, hbbs listens on IPv6 sockets (and does not listen at all on IPv4).

How to Reproduce

Fresh install of hbbs / hbbr using debian .deb packages, on Debian 12 VM. The VM has IPv6 disabled, and has only one IPv4 configured. When running hbbs, and checking with netstat -an, it only listens on IPv6 sockets (which are supposed to be disabled), and it does not listen on IPv4 sockets.

Expected Behavior

1/ Listen on the default IPv4 address sockets
2/ Allow to specify manually on which network card / IP address to bind

Operating system(s) on local side and remote side

Debian 12

RustDesk Version(s) on local side and remote side

1.1.10-3

Screenshots

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:15:5d:00:02:b8 brd ff:ff:ff:ff:ff:ff inet 10.111.222.20/24 brd 10.111.222.255 scope global eth0 valid_lft forever preferred_lft forever

netstat -an | grep 2111
tcp6 0 0 :::21117 :::* LISTEN
tcp6 0 0 :::21116 :::* LISTEN
tcp6 0 0 :::21119 :::* LISTEN
tcp6 0 0 :::21118 :::* LISTEN
tcp6 0 0 :::21115 :::* LISTEN
udp6 0 0 :::21116 :::*

Additional Context

No response

Originally created by @bc-109 on GitHub (Feb 5, 2024). ### Bug Description On Debian machine with only IPv4 enabled, hbbs listens on IPv6 sockets (and does not listen at all on IPv4). ### How to Reproduce Fresh install of hbbs / hbbr using debian .deb packages, on Debian 12 VM. The VM has IPv6 disabled, and has only one IPv4 configured. When running hbbs, and checking with netstat -an, it only listens on IPv6 sockets (which are supposed to be disabled), and it does not listen on IPv4 sockets. ### Expected Behavior 1/ Listen on the default IPv4 address sockets 2/ Allow to specify manually on which network card / IP address to bind ### Operating system(s) on local side and remote side Debian 12 ### RustDesk Version(s) on local side and remote side 1.1.10-3 ### Screenshots `ip a` `1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever` `2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:15:5d:00:02:b8 brd ff:ff:ff:ff:ff:ff inet 10.111.222.20/24 brd 10.111.222.255 scope global eth0 valid_lft forever preferred_lft forever` `netstat -an | grep 2111` `tcp6 0 0 :::21117 :::* LISTEN ` `tcp6 0 0 :::21116 :::* LISTEN ` `tcp6 0 0 :::21119 :::* LISTEN ` `tcp6 0 0 :::21118 :::* LISTEN ` `tcp6 0 0 :::21115 :::* LISTEN ` `udp6 0 0 :::21116 :::* ` ### Additional Context _No response_

deekerman

2026-02-21 00:22:50 -05:00

closed this issue
added the
bug
label

deekerman commented

2026-02-21 00:22:53 -05:00

Author

Owner

@rustdesk commented on GitHub (Feb 5, 2024):

#763

@rustdesk commented on GitHub (Feb 5, 2024): #763

deekerman commented

2026-02-21 00:22:53 -05:00

Author

Owner

@bc-109 commented on GitHub (Feb 6, 2024):

Please, could you explain with a little bit more words why you flagged this as "completed" ?

#763 is about custom builds. This is not a custom build, this is the latest .deb package from GitHub.
The problem is related to the ability to "bind" the hbbs server to a specific IP or interface. I did not find how to do that. Most server software have the ability to specify the IP on which we would like it to bind. I found a command-line switch to specify the port on which I would like it to listen. But nothing about the IP.
Having hbbs bound to tcp6 / udp6 ports on a machine with no IPv6 configured may be an expected behavior; but if so, it would require some explanations :-)

Kind regards

@bc-109 commented on GitHub (Feb 6, 2024): Please, could you explain with a little bit more words why you flagged this as "completed" ? - #763 is about custom builds. This is not a custom build, this is the latest .deb package from GitHub. - The problem is related to the ability to "bind" the hbbs server to a specific IP or interface. I did not find how to do that. Most server software have the ability to specify the IP on which we would like it to bind. I found a command-line switch to specify the port on which I would like it to listen. But nothing about the IP. - Having hbbs bound to tcp6 / udp6 ports on a machine with no IPv6 configured may be an expected behavior; but if so, it would require some explanations :-) Kind regards

deekerman commented

2026-02-21 00:22:53 -05:00

Author

Owner

@bc-109 commented on GitHub (Feb 22, 2024):

Hi,

I made a new install on different VM, on different location, with different OS (Ubuntu), and with default network configuration (both IPv6 and IPv6 addresses).

Same weird behavior :

In UDP, the server listens in IPv4 and IPv6
In TCP, it listens only in IPv6

As only IPv4 is available on the WAN link and on the gateway router, this leads to the following behavior :

On LAN, all works perfectly
On WAN, the client connects to the server (through UDPv4) but it's impossible to take control over another machine (as the server does not listen on TCPv4).

The faulty code seems to be here. I don't really know Rust language, but I would say if IPv6 socket succeeds, it does not ever try to open an IPv4 socket :
github.com/rustdesk/rustdesk@1f557888f5/libs/hbb_common/src/tcp.rs (L279C1-L286C10)

Moreover, I still don't understand why this bug has been closed without any explanation. Does that mean I have to fork the project, learn Rust and try to solve by myself ?

Kind regards

@bc-109 commented on GitHub (Feb 22, 2024): Hi, I made a new install on different VM, on different location, with different OS (Ubuntu), and with default network configuration (both IPv6 and IPv6 addresses). Same weird behavior : - In UDP, the server listens in IPv4 and IPv6 - In TCP, it listens only in IPv6 As only IPv4 is available on the WAN link and on the gateway router, this leads to the following behavior : - On LAN, all works perfectly - On WAN, the client connects to the server (through UDPv4) but it's impossible to take control over another machine (as the server does not listen on TCPv4). The faulty code seems to be here. I don't really know Rust language, but I would say if IPv6 socket succeeds, it does not ever try to open an IPv4 socket : https://github.com/rustdesk/rustdesk/blob/1f557888f5a61991d86928a6ab814dd21ac82b56/libs/hbb_common/src/tcp.rs#L279C1-L286C10 Moreover, I still don't understand why this bug has been closed without any explanation. Does that mean I have to fork the project, learn Rust and try to solve by myself ? Kind regards

deekerman commented

2026-02-21 00:22:53 -05:00

Author

Owner

@ron-1986 commented on GitHub (Feb 27, 2024):

@bc-109 Hey, I had the same problem on a Debian 11 lxc container. The deamons would listen on ipV6 only.

The only way to work around the problem for me was to disable ipv6 completely in GRUB on the host running the containers.
(Method 2 here: https://www.golinuxcloud.com/linux-disable-ipv6/)

Disabling IPv6 with sysctl did not work.

This is kind of an ugly workaround because it wouldn't work if some services on the machine rely on ipV6.

Choosing the interface/ip a server is listening on seems to be a very basic config option, that is clearly missing with RustDesk.
I would agree, that this issue shouldn't be closed, as the linked FAQ in #763 doesn't provide a solution for it.

Still a very nice project.

@ron-1986 commented on GitHub (Feb 27, 2024): @bc-109 Hey, I had the same problem on a Debian 11 lxc container. The deamons would listen on ipV6 only. The only way to work around the problem for me was to disable ipv6 completely in GRUB on the host running the containers. (Method 2 here: https://www.golinuxcloud.com/linux-disable-ipv6/) Disabling IPv6 with sysctl did not work. This is kind of an ugly workaround because it wouldn't work if some services on the machine rely on ipV6. Choosing the interface/ip a server is listening on seems to be a very basic config option, that is clearly missing with RustDesk. I would agree, that this issue shouldn't be closed, as the linked FAQ in #763 doesn't provide a solution for it. Still a very nice project.

deekerman commented

2026-02-21 00:22:53 -05:00

Author

Owner

@OXERY commented on GitHub (Apr 8, 2024):

The only way to work around the problem for me was to disable ipv6 completely in GRUB on the host running the containers. (Method 2 here: https://www.golinuxcloud.com/linux-disable-ipv6/)

Many thanks for that @wonder75 !! Only workaround that got my Docker-based Rustdesk-Pro-Setup running.

@OXERY commented on GitHub (Apr 8, 2024): > The only way to work around the problem for me was to disable ipv6 completely in GRUB on the host running the containers. (Method 2 here: https://www.golinuxcloud.com/linux-disable-ipv6/) Many thanks for that @wonder75 !! Only workaround that got my Docker-based Rustdesk-Pro-Setup running.

deekerman commented

2026-02-21 00:22:53 -05:00

Author

Owner

@xlinx commented on GitHub (Jan 28, 2025):

Please, could you explain with a little bit more words why you flagged this as "completed" ?

No build (including runtime error of your build), win7/8, ARM 32 / Pi 32, self-hosting setup / connection / deployment, and customization solution related issues / discussions please. #763 is about custom builds. This is not a custom build, this is the latest .deb package from GitHub.

The problem is related to the ability to "bind" the hbbs server to a specific IP or interface. I did not find how to do that. Most server software have the ability to specify the IP on which we would like it to bind. I found a command-line switch to specify the port on which I would like it to listen. But nothing about the IP.

Having hbbs bound to tcp6 / udp6 ports on a machine with no IPv6 configured may be an expected behavior; but if so, it would require some explanations :-)

Kind regards

I have the same feeling, too. There is no option for specific host only port, and I think it's not a discussion on discord; this is a issue.

hbbr 1.1.14
USAGE:
    hbbr [OPTIONS]

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -k, --key <KEY>                       Only allow the client with the same key
    -p, --port <NUMBER(default=21117)>    Sets the listening port

@xlinx commented on GitHub (Jan 28, 2025): > Please, could you explain with a little bit more words why you flagged this as "completed" ? > > * [No build (including runtime error of your build), win7/8, ARM 32 / Pi 32, self-hosting setup / connection / deployment, and customization solution related issues / discussions please. #763](https://github.com/rustdesk/rustdesk/discussions/763) is about custom builds. This is not a custom build, this is the latest .deb package from GitHub. > * The problem is related to the ability to "bind" the hbbs server to a specific IP or interface. I did not find how to do that. Most server software have the ability to specify the IP on which we would like it to bind. I found a command-line switch to specify the port on which I would like it to listen. But nothing about the IP. > * Having hbbs bound to tcp6 / udp6 ports on a machine with no IPv6 configured may be an expected behavior; but if so, it would require some explanations :-) > > Kind regards I have the same feeling, too. There is no option for specific host only port, and I think it's not a discussion on discord; this is a issue. ``` hbbr 1.1.14 USAGE: hbbr [OPTIONS] FLAGS: -h, --help Prints help information -V, --version Prints version information OPTIONS: -k, --key <KEY> Only allow the client with the same key -p, --port <NUMBER(default=21117)> Sets the listening port ```

Rows
Columns

On Debian 12 VM with IPv6 disabled, hbbs listens on IPv6 sockets, and does not listen on IPv4 #2464

Bug Description

How to Reproduce

Expected Behavior

Operating system(s) on local side and remote side

RustDesk Version(s) on local side and remote side

Screenshots

Additional Context