tcp listening tests always fail with goss 0.4.9 if ipv6 present

[sshipway]

Describe the bug
Defining a tcp test as "tcp:443" or as "tcp4:443"
Port 443 is listening on 0.0.0.0 (tcp4 only)
Goss reports this as "expected false to equal true"

This test worked prior to the 0.4.9 upgrade (version 0.3.20) when no ipv6 present

Could it be related to tcp6 (which is now enabled on this host)? However even using 'tcp4:80' I still get a fail

How To Reproduce

• Have host with both ipv4 and ipv6 addresses
• Have apache running listening on port 80, tcp4
• verify connection (telnet localhost 80)
• create goss rule

port:
  tcp4:80:
    listening: true

• Run goss test on this
• See that it fails

Expected Behavior
The test should pass, as the port is being listened on and can be connected to by telnet

Actual Behavior
test failed, even though it passed under goss 0.3.20, and the port is definitely listening

Environment:

• Version of goss
• OS/Distribution version (if applicable)

[aelsabbahy]

Is it related to the note here: https://goss.readthedocs.io/en/stable/gossfile/#port

If so, I'd love to know which tools handle this correctly so I can see how they do it.

The alternative is to just to have tcp and make no distinction between 4 and 6 unless the user specified an ip address that it's listening to.

Goss might consider your port to be listening on tcp6 rather than tcp, try running goss add port .. to see how goss detects it. (explanation)

[sshipway]

Since logging this, we removed IPv6 from the system, so Ive set up a new one.

Verifying test environment (no ip6 address though it is enabled in kernel)

$ netstat -lnt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN 
$ ifconfig -a
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.63.20.100  netmask 255.255.255.224  broadcast 10.63.20.127

Goss file

port:
  tcp:8080:
    listening: true
  tcp4:8080:
    listening: true
  tcp6:8080:
    listening: false

Result

goss -g ./test.yaml v
F..

Failures/Skipped:

Port: tcp4:8080: listening:
Expected
    false
to equal
    true

Total Duration: 0.000s
Count: 3, Failed: 1, Skipped: 0

with "goss add port 8080"

port:
    tcp:8080:
        listening: true
        ip:
            - 0.0.0.0

So it seems that explicit ipv4 tets such as 'tcp4:8080' fail, even though the port is listening on tcp4, but only if ipv6 is enabled in the kernel. Using 'tcp:8080' works, and correctly says the port is up. This is not quite what I saw previously? However this does not allow us to verify that the port is explicitly on ipv4 (we had a problem in the past where the system listened only on ipv6 but goss tests passed)
(fixed top issue details to match)