interface selection

[Pentium4User]

Hello!
I have 2 Debian Sid systems. One has several interfaces, not all have addresses attached (bridge, VLAN-Trunk etc.). One of them has IPv4/IPv6 and works fine.

m@ryz:~$ LANG=C testssl -6 [2a00:1450:4001:828::2003]

#####################################################################
testssl version 3.2rc4 from https://testssl.sh/dev/

This program is free software. Distribution and modification under
GPLv2 permitted. USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

Please file bugs @ https://testssl.sh/bugs/

#####################################################################

Using OpenSSL 3.5.0 8 Apr 2025 [~103 ciphers]
on ryz:/usr/bin/openssl

Start 2025-04-13 11:48:04 -->> [2a00:1450:4001:828::2003]:443 (2a00:1450:4001:828::2003) <<--

rDNS (2a00:1450:4001:828::2003): fra24s05-in-x03.1e100.net./usr/bin/testssl: line 11830: 2a00:1450:4001:828::2003: Address family for hostname not supported
/usr/bin/testssl: line 11830: /dev/tcp/2a00:1450:4001:828::2003/443: Invalid argument
Oops: TCP connect problem

Unable to open a socket to [2a00:1450:4001:828::2003]:443.
Fatal error: Can't connect to "[2a00:1450:4001:828::2003]:443"
Make sure a firewall is not between you and your scanning target!

m@ryz:~$

m@ryz:~$ 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
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 08:xxxxxx brd ff:ff:ff:ff:ff:ff
    altname enxxxxxx
3: vlan2@enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 08:xxxxxxx brd ff:ff:ff:ff:ff:ff
    inet 82.xxxxxx/32 scope global noprefixroute vlan2
       valid_lft forever preferred_lft forever
    inet6 2a01:170:xxxxx/64 scope global temporary dynamic 
       valid_lft 592010sec preferred_lft 73084sec
    inet6 2a01:170:xxxxx/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 2591821sec preferred_lft 604621sec
    inet6 fe80::xxxxx/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: vlan5@enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 08xxxxx brd ff:ff:ff:ff:ff:ff
5: bridge0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 6a:xxxxxx brd ff:ff:ff:ff:ff:ff
6: vboxnet0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 0a:xxxxx brd ff:ff:ff:ff:ff:ff
    altname enxxxxx
7: vboxnet1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 0a:xxxx brd ff:ff:ff:ff:ff:ff
    altname enxxxxx
m@ryz:~$ 

Is that a problem with interface selection?
It works fine in a Debian sidvirtual machine with only a single interface

[drwetter]

Hi,
I can't tell what's wrong as this works for me (tm) :-)

From what you said I'd rather guess it's a problem with the networking like default route or netmask. Check if wget or curl works. There seem to be a even problem with rDNS / PTR records to begin with.

Also, as other applications, testssl.sh doesn't do any interface selection, that's another layer we don't touch and care .

Closing this, if you still believe it's "our" problem I am happy to reopen

[Pentium4User]

TLDR: I assume an issue in my OS Am 15.04.2025 um 10:13:22 Uhr schrieb Dirk Wetter:

From what you said I'd rather guess it's a problem with the networking like default route or netmask.

No, it clearly isn't. Routes are fine.

Check if wget or curl works.

They work, the issue only exist with testssl on this specific system.

There seem to be a even problem with rDNS / PTR records to begin with.

I don't see how that would affect testssl when doing TLS test - those tests don't even beging. If I use hostname with proper DNS the behavior is the same.

Also, as other applications, testssl.sh doesn't do any interface selection, that's another layer we don't touch and care .

I agree with that, I thought that this might be one of the issues, but it doesn't seem so. My system has working IPv6 connectivity, I use that protocol on a regular base. An strace gives me write(2, "/usr/bin/testssl: line 11830: /d"..., 86/usr/bin/testssl: line 11830: /dev/tcp/2a00:1450:4001:828::2003/443: Invalid argument I've now tested that, it does not work with IPv6 addresses in the path as testssl does, only on this system in this test case. ***@***.***:~$ echo bla > /dev/tcp/google.de/80 ***@***.***:~$ echo bla > /dev/tcp/2a00:1450:4001:808::2003/80 bash: 2a00:1450:4001:808::2003: Die Adressfamilie für Hostnamen wird nicht unterstützt bash: /dev/tcp/2a00:1450:4001:808::2003/80: Das Argument ist ungültig ***@***.***:~$ echo bla > /dev/tcp/172.217.16.13/80 ***@***.***:~$ Exactly that syntax works on another Debian Sid virtual machine, I assume a problem with my system or a specific config issue. I will now try to investigate that further.

…

-- Gruß Marco

[drwetter]

Debian sid === Debian trixie?

@.***:~$ echo bla > /dev/tcp/2a00:1450:4001:808::2003/80

That works for me on trixie with bash version 5.2.37(1) .

Pls have a look at line 11830 what that is. Also maybe you're using the Debian version from testssl?

[Pentium4User]

Am 16.04.2025 um 02:11:44 Uhr schrieb Dirk Wetter:

drwetter left a comment (testssl/testssl.sh#2738) Debian sid === Debian trixie?

At this time yes.

> ***@***.***:~$ echo bla > /dev/tcp/2a00:1450:4001:808::2003/80 That works for me on trixie with bash version 5.2.37(1) .

I can confirm this on another sid/trixie machine, so I assume the issue is related to my own productive machine only, not to testssl. I will try to find the cause.

Pls have a look at line 11830 what that is.

if [[ -z "$PROXY" ]] && ! exec 5<>/dev/tcp/$nodeip/$PORT; then

Also maybe you're using the Debian version from testssl?

Yes, I use the version from the Debian repo on both machines.

…

-- Gruß Marco Send unsolicited bulk mail to ***@***.***