Bug#864230: xrdp: Bad IPv4 and IPv6 support
Santiago Garcia Mantinan
manty at debian.org
Mon Jun 5 13:14:39 UTC 2017
Package: xrdp
Version: 0.9.1-9
Severity: important
Dear Maintainer,
Installing xrdp with default config on a IPv4 only machine
(GRUB_CMDLINE_LINUX="ipv6.disable=1") results on xrdp not being able to
contact sesman which is listening 127.0.0.1:3350.
The messages one can see on xrdp log are:
[20170605-15:01:41] [ERROR] g_tcp_socket: Address family not supported by protocol
[20170605-15:01:41] [INFO ] IPv6 not supported, falling back to IPv4
[20170605-15:01:41] [ERROR] g_tcp_connect: getaddrinfo() failed: Name or service not known
[20170605-15:01:41] [ERROR] g_tcp_connect: getaddrinfo() failed: Name or service not known
[20170605-15:01:42] [ERROR] g_tcp_connect: getaddrinfo() failed: Name or service not known
[20170605-15:01:43] [ERROR] g_tcp_connect: getaddrinfo() failed: Name or service not known
[20170605-15:01:43] [ERROR] g_tcp_connect: getaddrinfo() failed: Name or service not known
[20170605-15:01:44] [ERROR] g_tcp_connect: getaddrinfo() failed: Name or service not known
[20170605-15:01:45] [ERROR] xrdp_wm_log_msg: Error connecting to sesman: 127.0.0.1 port: 3350
[20170605-15:01:45] [DEBUG] Closed socket 22 (AF_INET 0.0.0.0:0)
[20170605-15:01:45] [DEBUG] return value from xrdp_mm_connect 1
When I saw this problem I tried to add IPv6 support to the machine thinking
this would solve the issue, but then I came up with sesman only listening on:
tcp6 0 0 ::1:3350 :::* LISTEN 393/xrdp-sesman
and xrdp trying to connect to 127.0.0.1:3350 (as seen on tcpdump).
As a workaround I installed haproxy with this setup:
frontend sesmanipv4
bind 127.0.0.1:3350
mode tcp
option tcplog
default_backend sesmanipv6
backend sesmanipv6
mode tcp
server local ::1:3350
which basically tells haproxy to listen on localhost via IPv4 and forward
traffic to localhost on IPv6 and solves the problem.
when looking at the xrdp project on github it looks that on the latest devel
code they have reimplemented the common/os_calls.c part that is failing to
connect. I believe that this reimplementation may also fix bug #858098 which
is also related to this.
I also tried the xrdp version on experimental with same results as shown here.
Regards.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=gl_ES.UTF-8, LC_CTYPE=gl_ES.UTF-8 (charmap=UTF-8), LANGUAGE=gl_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages xrdp depends on:
ii adduser 3.115
ii init-system-helpers 1.48
ii libc6 2.24-11
ii libfuse2 2.9.7-1
ii libjpeg62-turbo 1:1.5.1-2
ii libopus0 1.2~alpha2-1
ii libpam0g 1.1.8-3.6
ii libssl1.1 1.1.0e-2
ii libx11-6 2:1.6.4-3
ii libxfixes3 1:5.0.3-1
ii libxrandr2 2:1.5.1-1
ii lsb-base 9.20161125
ii ssl-cert 1.0.39
Versions of packages xrdp recommends:
ii fuse 2.9.7-1
ii xorgxrdp 0.9.1-9
Versions of packages xrdp suggests:
pn guacamole <none>
Versions of packages xorgxrdp depends on:
ii libc6 2.24-11
pn xorg-input-abi-24 <none>
ii xserver-xorg-core [xorg-video-abi-23] 2:1.19.2-1
Versions of packages xorgxrdp recommends:
ii xorg 1:7.7+19
-- no debconf information
More information about the pkg-remote-team
mailing list