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