Replies: 0 comments 25 replies
-
|
I tried to open a bug, but it has been closed with no explanation : I agree, this may not be a bug, this may be a "lack of feature" (c) :-) For now, hbbs does not listen on my IPv4 address. So, it's pretty useless... |
Beta Was this translation helpful? Give feedback.
-
|
Hi, Bug #7056 is still closed, I have no idea why. In the meantime, a friend of mine 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 :
As only IPv4 is available on the WAN link and on the gateway router, this leads to the following behavior :
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 : As this behavior has been seen on two different locations, on two different VMs and OSes, on two different installations made by two different people, I can't imagine we're the only guys facing that problem... Does that mean RustDesk is IPv6 only, and IPv4 / dual stack is not supported at all ? KInd regards |
Beta Was this translation helpful? Give feedback.
-
|
Same thing, and there's no way to tell it to listen on ipv4, it only listens on ipv6, use debian 12 distro. |
Beta Was this translation helpful? Give feedback.
-
|
version: '3' networks: services: hbbr: |
Beta Was this translation helpful? Give feedback.
-
|
Hi @monat78. Please, could you explain the previous post with some words ? This post seems to show some data about hbbs / hbbr running in containers, and it does not show any distinction between IPv4 and IPv6. My bug report was about running hbbs / hbbr on bare Linux machines (Debian and Ubuntu), without any container. What I said is that when hbbs binds to IPv6, it does not ever try to bind to IPv4. And, a sub-problem is that it manages to bind on IPv6 even on machines where there's no IPv6 ! This is not a correct behavior. "Dual stack" good practices, where both IPv4 and IPv6 are active, is to bind on both protocols for incoming connections. For outgoing connections, good practices are to try IPv6 first, and if it fails, try IPv4. I browsed the source, and I pointed out a piece of code where I think the problem resides. Anyway, I'm not a Rust programmer, and I can't solve the problem by mysef. Does your answer mean RustDesk does not support IPv4 ? Or that RustDesk is supported only inside containers ? Thank you in advance. Kind regards |
Beta Was this translation helpful? Give feedback.
-
|
I have encountered exactly the same problem on ubuntu 22.04. So I forked a copy of the rustdesk-server repository on github and did some tinkering in the code. I added some diagnostics to the new_socket functions in tcp.rs and udp.rs. I also have zero knowledge of rust! However I managed to cobble together something that built. This showed that only ipv6 addresses were being asked for! This means that the problem must be in the server default config. The config mechanism seems to be pretty much undocumented. The only thing I could find was some environment variables in the the top level REAMDE.md. My next step is to set RUST_LOG=trace and see what I can find. |
Beta Was this translation helpful? Give feedback.
-
|
Here are the mods. Here is the trace log. I still have not got as clue as to why no ipv4 addresses are being requested. I think the answer my lie somewhere in socket_client.rs. Rust expertise urgently required! |
Beta Was this translation helpful? Give feedback.
-
|
I now tracked the problem to these two files. index 0c0d107..af3eab3 100644
--- a/src/rendezvous_server.rs +++ b/src/rendezvous_server.rs
@@ -1296,7 +1296,7 @@ async fn create_udp_listener(port: i32, rmem: usize) -> ResultType<FramedSocket>
let addr = SocketAddr::new(IpAddr::V6(Ipv6Addr::UNSPECIFIED), port as _);
if let Ok(s) = FramedSocket::new_reuse(&addr, false, rmem).await {
log::debug!("listen on udp {:?}", s.local_addr());
- return Ok(s);
+ // return Ok(s); }
let addr = SocketAddr::new(IpAddr::V4(Ipv4Addr::UNSPECIFIED), port as _);
let s = FramedSocket::new_reuse(&addr, false, rmem).await?;This patch fixes the udp ports and seems to work. index f574e83..0c6be48 100644
--- a/libs/hbb_common/src/tcp.rs
+++ b/libs/hbb_common/src/tcp.rs
@@ -282,8 +282,10 @@ pub async fn listen_any(port: u16) -> ResultType<TcpListener> {
.bind(SocketAddr::new(IpAddr::V6(Ipv6Addr::UNSPECIFIED), port))
.is_ok()
{
- if let Ok(l) = socket.listen(DEFAULT_BACKLOG) {
- return Ok(l);
+ if let Ok(_l) = socket.listen(DEFAULT_BACKLOG) {
+ /*
+ return Ok(l);
+ */
}This patch compiles but results in ipv6 being disabled. My non-existent knowledge of rust means I haven't a clue on how to fix it. The only way forward I can see is to raise this a pull request and ask for a code review. |
Beta Was this translation helpful? Give feedback.
-
|
You'd better try deploy though docker And the reason why your issues got closed is because you should post your issues at discussions, issues only store organized issues about devs. And you said:
I hope you look carefully. |
Beta Was this translation helpful? Give feedback.
-
|
I have created pull request #395 |
Beta Was this translation helpful? Give feedback.
-
|
I also tried the work around of using the latest docker images. These exhibit exactly the same problem as the bare metal version. IPv6 ports only! |
Beta Was this translation helpful? Give feedback.
-
|
I get the same erroneous behaviour on a newly-created VM (the current standard Ubuntu 22.04 image used by Windows 11 Hyper-V Quick Create) and just following the instructions at https://rustdesk.com/docs/en/self-host/rustdesk-server-oss/install/ Clearly it's not working as intended... |
Beta Was this translation helpful? Give feedback.
-
|
Please build server on Linux, and docker is more recommend and more easy |
Beta Was this translation helpful? Give feedback.
-
Both the OP and myself are on Linux (Debian and Ubuntu respectively)! In my case, it is admittedly the version of Ubuntu 22.04 LTS that's supplied thru Windows Hyper-V, but it's still standard 22.04 LTS. I wonder if it doesn't have something to do with them trying to push IPv6 by deprecating some old IPv4 defaults. I might try on 20.04 LTS instead. I'll try the docker version as well... |
Beta Was this translation helpful? Give feedback.
-
|
I have no problem on both IPv6/IPv4 on both Ubuntu 22.04/24.04(testing) and Arch And all of them is using docker s6 image |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, that's helpful. If my theory (see below) is correct, then if you run
you will only see TCP6 listeners (as per the original post). My theory is that it is listening on IPv4 too, even though no IPv4 listeners are listed by netstat. In other words, there may never have been a problem, only a quirk in the netstat utility that makes it look like there is. |
Beta Was this translation helpful? Give feedback.
-
|
Update: my system is working properly -- and thus clearly listening -- on IPv4 despite netstat showing that it is only listening on IPv6. |
Beta Was this translation helpful? Give feedback.
-
|
By my count that makes at least five of us with the same issue (bc109, their friend, monat76, rogerjames109, and myself). There's clearly some systematic issue. |
Beta Was this translation helpful? Give feedback.
-
|
Perhaps the issue is not that IPv4 isn't enabled, just that netstat doesn't report them as listening. I note that a number of people have issues with confusion about nginx (appearing in netstat to be) not listening on IPv4, even when it actually is. Using ss (rather than the deprecated netstat) also shows the ports as listening with -lp and with -lp6, but not with -lp4: However, an external nmap scan of the box shows the ports responding to IPv4 ack scans: |
Beta Was this translation helpful? Give feedback.
-
|
Update: my system is working properly -- and thus clearly listening -- on IPv4 despite netstat showing that it is only listening on IPv6. Thus there never was an issue, only the appearance of one. I'm not entirely clear on why this is, perhaps IPv6 automatically deals with the IPv4 address space using the ::ffff:0:0/96 special address range that maps IPv4 addresses. In any case, I found several other software projects (e.g. nginx) which note a similar behaviour. |
Beta Was this translation helpful? Give feedback.
-
|
I have withdrawn my pull request. It was nonsensical! My only excuse is that I have been recovering from a bout of pneumonia and have lost the plot somewhat. The code is working as expected. When you create an ipv6socket, set the ipv6_only flag to false, and bind to the the ipv6 "any" address "[::]:*". The socket will accept ipv4 connections, but it will map the incoming ipv4 address into an ipv6 address using the standard rules. Here is an example. |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, I also encountered the same problem. I don’t want to hear too much theoretical knowledge. I just want to say that I can access through |
Beta Was this translation helpful? Give feedback.
-
|
You can force ip4 by adapting your for example services:
hbbs:
container_name: rustdesk-hbbs
image: rustdesk/rustdesk-server:latest
command: hbbs
volumes:
- ./data:/root
ports:
# 21114 TCP web console, only available in Pro version
# 21115 TCP for NAT type test
# 21116 UDP/TCP TCP Hole Punching / Heartbeat / ID-Server
# 21118 TCP Relay
- "192.168.0.200:21114-21116:21114-21116/tcp"
- "192.168.0.200:21118:21118/tcp"
- "192.168.0.200:21116:21116/udp"
depends_on:
- hbbr
restart: always
hbbr:
container_name: rustdesk-hbbr
image: rustdesk/rustdesk-server:latest
command: hbbr
volumes:
- ./data:/root
ports:
# 21117 TCP Relay
# 21119 TCP Relay
- "192.168.0.200:21117:21117/tcp"
- "192.168.0.200:21119:21119/tcp"
restart: alwaysFor me it works. In case you want to know more here is the official documentation which helped me. |
Beta Was this translation helpful? Give feedback.
-
it's not working for my rustdesk on ubuntun... |
Beta Was this translation helpful? Give feedback.
-
|
Check natstat If you still don't know why, reinstall OS |
Beta Was this translation helpful? Give feedback.
-
Hi,
I made a fresh install of hbbs / hbbr on a Debian 12 VM. IPv6 is disabled. The VM only has one IPv4 address :
ip a1: 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 forever2: 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 foreverWhen running hbbs, it seems to start listening on IPv6 sockets (that's funny on a machine with no IPv6 address ), and it does not listen at all on IPv4 sockets :
netstat -an | grep 2111tcp6 0 0 :::21117 :::* LISTENtcp6 0 0 :::21116 :::* LISTENtcp6 0 0 :::21119 :::* LISTENtcp6 0 0 :::21118 :::* LISTENtcp6 0 0 :::21115 :::* LISTENudp6 0 0 :::21116 :::*Moreover, I didn't find any configuration file / parameter where I could specify on which IP address I would like it to bind.
As it does not listen at all on IPv4 sockets, of course, it does not accept connections via IPv4 !
Thank you in advance
Beta Was this translation helpful? Give feedback.
All reactions