Connection refused at wss://ws-star.discovery.libp2p.io/socket.io/?EIO=3&transport=websocket when shouldnt be going there

[mitra42]

• Version: 0.31.7. (this is not output of ipfs.version, as ipfs.version fails)
• Platform: Firefox 62.0.2 or Chrome 69.0.3497
• Subsystem: ipfs connection via ws-star

Type: Bug

Severity: Critical

Description:

WebSocket connection to 'wss://ws-star.discovery.libp2p.io/socket.io/?EIO=3&transport=websocket' failed: Error in connection establishment: net::ERR_CONNECTION_REFUSED

when trying new IPFS(this.options);
with this.options =

"repo":"/tmp/dweb_ipfsv2700",
"config":{
"Bootstrap":["/dns4/dweb.me/tcp/4245/wss/ipfs/QmPNgKEjC7wkpu3aHUzKKhZmbEfiGzL5TP1L8zZoHJyXZW"]},
"EXPERIMENTAL":{"pubsub":true}
}

I've confirmed with sudo -u ipfs ipfs config show that this is the correct peer id of our peer,

I'm not sure why its hitting ws-star.discovery, and/or why that call is failing and suggest that either that address has gone down, or there's been a code update to add the ws-star discovery process.

This should be the version on dweb.archive.org unfortunately :-(

[mccoysc]

ws-star.discovery.libp2p.io is down

[parkan]

I think there is some stray bit of configuration somewhere that includes ws-star.discovery.libp2p.io, addressing this elsewhere -- can likely close this

[mitra42]

As long as ws-star.discovery.libp2p.io is up we are good, but there is a generic issue that may cause problems such as the numerous reports when that address was down, and also explains why some people had issues in FIrefox but not Chrome or vica-versa

By clearing my local storage in Chrome the client no longer tried to contact ws-star.discovery.libp2p.io which suggests that despite using a config to "new IPFS()" that didn't mention these addresses, that IPFS was ignoring its absence in my current config and finding the swarm from when the Repo was created in browser's indexedDB .

Is that what should happen?

[parkan]

ok, this generally overlaps with many other reports

libp2p/js-libp2p-websockets#74
#1185
ipfs-shipyard/peer-pad-core#13

and it looks like you've encountered this before, as well: #1237

the main issue here specifically appears to be that other ws connections should not be aborted if the signaling server connection fails (if they're being dialed directly) -- I can open that issue if you close this one

[mitra42]

The problem in #1237 was while we were intentionally using ws-star discovery. On Protocol's suggestion we moved to opening up direct connection with our own peer via WS.

There seem to be three separate issues,
a) reliability of that server - which as #1237 says shouldnt be relied on (and we don't intentionally)
b) failure of "new IPFS" when the ws-star.discovery fails, it probably shouldnt be dependent on it as long as it has some other connection mechanism.
c) that once a repo is initialized with a config that uses ws-star.discovery then it seems to remember that even if the repo is subsequently called with a different config.

Should b and c be seperate issues ? Its fine by me to create one or two and close this one.

[parkan]

(b) is the key issue, I believe (c) is just a matter of the peer being retained in the peer book (which would be harmless w/o (b))

can you close this one? I don't have rights on this repo