Trying to establish a bundle with the following two commands:

1. on node running on 192.168.2.10:

   cockroach connect --num-expected-initial-nodes 2 --init-token abc

2. on node running on 192.168.2.19:

   cockroach connect --num-expected-initial-nodes 2 --init-token abc --join=192.168.2.10:26257 --listen-addr=:26258 --http-addr=:8081

This fails with the following error/warning:

W210308 14:59:03.705454 39 1@server/init_handshake.go:389  [connect,init-tls-handshake,peer=192.168.2.10:] 1  peer CA retrieval error: Post
"https://192.168.2.10:26257/trustInit/
": dial tcp 192.168.2.10:26257: connect: connection refused
W210308 14:59:03.705769 1 1@server/init_handshake.go:546  [connect,init-tls-handshake] 2  error from client when connecting to peers (retrying): Post
"https://192.168.2.10:26257/
trustInit/": dial tcp 192.168.2.10:26257: connect: connection refused

Indeed, a display via netstat reveals that both commands have not started listening on the IPv4 external interface. Via verbose logging we can indeed see:

I210308 15:03:02.748784 1 1@cli/connect.go:83  [connect] 3  started rpc listener at: [::]:26257
I210308 15:03:02.748820 1 1@cli/connect.go:91  [connect] 4  started http listener at: [::]:8080

Listening on IPv6 may or may not be what the user actually wants, however it's problematic that the "default" (simpler argument) behavior gets a broken connect behavior with no visual indication of what's wrong.

The command should, at the very least, display on its standard output:

• which address(es) it's listening on, which are suitable for use with --join in other commands running on the same local network

• the list of addresses it's going to populate into its server certificates

Related to #60632

cc @aaron-crl @itsbilal

Jira issue: CRDB-6273
Epic: CRDB-6663