Thanks for the strace. We can see that sslh creates two sockets of the same
address family, on the same host and port:

[…]
[pid 23812] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 3
[pid 23812] setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
[pid 23812] setsockopt(3, SOL_IP, IP_FREEBIND, [1], 4) = 0
[pid 23812] bind(3, {sa_family=AF_INET, sin_port=htons(37229),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
[pid 23812] listen(3, 50)               = 0
[pid 23812] socket(AF_INET, SOCK_STREAM, IPPROTO_IP) = 4
[pid 23812] setsockopt(4, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
[pid 23812] setsockopt(4, SOL_IP, IP_FREEBIND, [1], 4) = 0
[pid 23812] bind(4, {sa_family=AF_INET, sin_port=htons(37229),
sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in
use)
[…]

Does the attached patch help by any chance? If not, could you supply a new
strace file, with both patches applied please?

On Sat, May 6, 2017 at 5:33 PM, Adam Borowski <kilob...@angband.pl> wrote:

> On Sat, May 06, 2017 at 04:57:09PM +0200, Michael Stapelberg wrote:
> > On Sat, May 6, 2017 at 4:02 PM, Adam Borowski <kilob...@angband.pl>
> wrote:
> >
> > > On Sat, May 06, 2017 at 03:44:42PM +0200, Michael Stapelberg wrote:
> > > > I pushed a commit adding a patch which fixes the test by picking an
> > > > unused port. The mechanism is not atomic (i.e., the port is picked by
> > > > the test process, as opposed to the listening process itself and
> > > > communicated back to the test process), but it’s an improvement and
> > > > should fix the issue at hand.
> > > >
> > > > gui, could you take care of preparing a new upload, and filing the
> > > > unblock request? Let me know if you don’t have time for it, and I
> can do
> > > > an NMU.
> > > >
> > > > For your convenience, I have also attached the patch to this message.
> > >
> > > >  create mode 100644 debian/patches/fix-ftbfs-static-port.patch
> > >
> > > Nope, I'm afraid it still fails.
> > >
> >
> > Huh. Can you attach an strace of running the tests please?
>
> Sure, 'ere you go.
>
> > Do you have any funky business going on with regards to your IPv4/IPv6
> > setup?
>
> .--====[ armhf that fails ]
> auto lo
> iface lo inet loopback
>
> auto eth0
> iface eth0 inet6 static
>         address 2001:6a0:118::5
>         netmask 64
>         gateway 2001:6a0:118::90
> iface eth0 inet static
>         address 10.0.1.5
>         netmask 255.255.255.0
>         gateway 10.0.1.90
> +--====[ arm64 that succeeds (chroots: armhf arm64) ]
> auto lo
> iface lo inet loopback
>
> auto eth0
> iface eth0 inet static
>         address 10.0.1.9
>         netmask 255.255.255.0
>         gateway 10.0.1.90
> iface eth0 inet6 static
>         address 2001:6a0:118::9
>         netmask 64
>         gateway 2001:6a0:118::90
> `----
>
> The amd64 box (chroots: amd64 i386 x32 armhf/qemu-user arm64/qemu-user) has
> br0 that's the only configured and up interface, all other config is
> dormant.
> Virtual machines are also boring.
>
>
> > Firewall rules?
>
> [~]# iptables -L
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> [~]# iptables -L -t nat
> Chain PREROUTING (policy ACCEPT)
> target     prot opt source               destination
>
> Chain INPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
>
> Chain POSTROUTING (policy ACCEPT)
> target     prot opt source               destination
>
>
> Meow!
> --
> Don't be racist.  White, amber or black, all beers should be judged based
> solely on their merits.  Heck, even if occasionally a cider applies for a
> beer's job, why not?
> On the other hand, corpo lager is not a race.
>



-- 
Best regards,
Michael
From d9855452c9a3dc3063653c4ee80d3f82fb363ea7 Mon Sep 17 00:00:00 2001
From: Michael Stapelberg <stapelb...@debian.org>
Date: Sat, 6 May 2017 18:31:03 +0200
Subject: [PATCH] add addr_family.patch

---
 debian/patches/addr_family.patch | 23 +++++++++++++++++++++++
 debian/patches/series            |  1 +
 2 files changed, 24 insertions(+)
 create mode 100644 debian/patches/addr_family.patch

diff --git a/debian/patches/addr_family.patch b/debian/patches/addr_family.patch
new file mode 100644
index 0000000..5311498
--- /dev/null
+++ b/debian/patches/addr_family.patch
@@ -0,0 +1,23 @@
+Index: sslh/common.c
+===================================================================
+--- sslh.orig/common.c
++++ sslh/common.c
+@@ -91,7 +91,6 @@ int get_fd_sockets(int *sockfd[])
+    */
+ int start_listen_sockets(int *sockfd[], struct addrinfo *addr_list)
+ {
+-   struct sockaddr_storage *saddr;
+    struct addrinfo *addr;
+    int i, res, one;
+    int num_addr = 0;
+@@ -116,9 +115,8 @@ int start_listen_sockets(int *sockfd[],
+            fprintf(stderr, "FATAL: Inconsistent listen number. This should not happen.\n");
+            exit(1);
+        }
+-       saddr = (struct sockaddr_storage*)addr->ai_addr;
+ 
+-       (*sockfd)[i] = socket(saddr->ss_family, SOCK_STREAM, 0);
++       (*sockfd)[i] = socket(addr->ai_family, SOCK_STREAM, 0);
+        check_res_dumpdie((*sockfd)[i], addr, "socket");
+ 
+        one = 1;
diff --git a/debian/patches/series b/debian/patches/series
index faf6fff..45e1ac3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@ disable_valgrind_launch.diff
 ftbfs_localhost.diff
 transparent_mode_local.diff
 fix-ftbfs-static-port.patch
+addr_family.patch
-- 
2.11.0

Reply via email to