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
It seems like mDNS discovery only picks up the "first" interface that libp2p finds, i.e. usually the first one that's printed on ipfs startup. In my case, that's OpenVPN's tun0, but not the LAN's wifi0. Other interfaces aren't considered, so discovery is half broken in those cases.
We should probably apply some simple heuristics to decide which interfaces look like they're probably a LAN.
> IPFS_LOGGING=debug ipfs daemon |& grep mdns
The text was updated successfully, but these errors were encountered:
ghost
added
the
kind/bug
A bug in existing code (including security flaws)
label
Dec 13, 2017
👍 I've run into this as well, it's a problem on Android devices where a multiplexing interface may appear with an IP that isn't reachable from anything but the host device. When this address gets advertised, it's a bad time for mDNS
It seems like mDNS discovery only picks up the "first" interface that libp2p finds, i.e. usually the first one that's printed on ipfs startup. In my case, that's OpenVPN's tun0, but not the LAN's wifi0. Other interfaces aren't considered, so discovery is half broken in those cases.
We should probably apply some simple heuristics to decide which interfaces look like they're probably a LAN.
The text was updated successfully, but these errors were encountered: