You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
OS: Linux (Arch Linux x86_64, Kernel 7.2 / Flatpak / native)
Version of IPFS Desktop: 0.50.0 / 0.50.1
Describe the bug
When a local Kubo daemon is already running, IPFS Desktop should detect and attach to it seamlessly. Currently, this fails due to two sequential issues:
Gateway probe false positive (PR fix: probe HTTP gateways independently of the RPC API #3217): checkIfAddrIsDaemon() sends an RPC POST /api/v0/refs... to the gateway port (which returns 404), triggering a false "Ports are busy" prompt instead of recognizing the node.
Crash on modern multiaddrs (PR fix: replace ipfs-http-client with kubo-rpc-client #3034): During handshake (id()), legacy multiaddr@10.0.1 fails on modern Kubo addresses (e.g. /tls/, /quic-v1/ from AutoTLS) with Error: no protocol with name: tls, aborting startup and leaving WebUI failing at 127.0.0.1:5001.
To Reproduce
Steps to reproduce the behavior:
Start an external Kubo daemon (v0.33+ / 0.43+) on custom ports (e.g. API 5003, Gateway 8084) with "AutoTLS": { "Enabled": true }.
Point IPFS Desktop to this repository (via IPFS_PATH or ~/.ipfs).
Launch IPFS Desktop.
Observe the "Ports are busy" modal dialog:
"The ports 5003 and 8084 are not available. Do you want to use 5004 and 8085 instead?"
Notice WebUI opens but fails to connect, falling back to http://127.0.0.1:5001.
Expected behavior
IPFS Desktop recognizes the ports belong to a running daemon ([daemon] ports busy by a daemon).
It attaches to the existing daemon without spawning a duplicate process or prompting to change ports.
It parses node addresses without crashing on modern protocols.
WebUI automatically launches with ?api=/ip4/127.0.0.1/tcp/<API_PORT>.
Additional context
Stack trace from combined.log:
error: [ipfsd] start daemon Error: no protocol with name: tls
at Protocols (.../node_modules/multiaddr/src/protocols-table.js:22:11)
at stringToStringTuples (.../node_modules/multiaddr/src/codec.js:48:19)
at stringToBytes (.../node_modules/multiaddr/src/codec.js:220:13)
at Object.fromString (.../node_modules/multiaddr/src/codec.js:231:10)
at new Multiaddr (.../node_modules/multiaddr/src/index.js:56:26)
at .../node_modules/ipfs-http-client/cjs/src/id.js:23:53
at Array.map (<anonymous>)
at Object.id (.../node_modules/ipfs-http-client/cjs/src/id.js:23:43)
at async Daemon.start (.../node_modules/ipfsd-ctl/src/ipfsd-daemon.js:268:16)
Describe the bug
When a local Kubo daemon is already running, IPFS Desktop should detect and attach to it seamlessly. Currently, this fails due to two sequential issues:
checkIfAddrIsDaemon()sends an RPCPOST /api/v0/refs...to the gateway port (which returns 404), triggering a false "Ports are busy" prompt instead of recognizing the node.id()), legacymultiaddr@10.0.1fails on modern Kubo addresses (e.g./tls/,/quic-v1/from AutoTLS) withError: no protocol with name: tls, aborting startup and leaving WebUI failing at127.0.0.1:5001.To Reproduce
Steps to reproduce the behavior:
5003, Gateway8084) with"AutoTLS": { "Enabled": true }.IPFS_PATHor~/.ipfs).combined.log:error: [ipfsd] start daemon Error: no protocol with name: tlshttp://127.0.0.1:5001.Expected behavior
[daemon] ports busy by a daemon).?api=/ip4/127.0.0.1/tcp/<API_PORT>.Additional context
Stack trace from
combined.log: