Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mdns is squating on host hostname #176

Closed
daviddias opened this issue Jan 17, 2017 · 14 comments · Fixed by #1161
Closed

mdns is squating on host hostname #176

daviddias opened this issue Jan 17, 2017 · 14 comments · Fixed by #1161
Labels
exp/wizard Extensive knowledge (implications, ramifications) required help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/deferred Conscious decision to pause or backlog

Comments

@daviddias
Copy link
Member

I've been debugging why jsipfs and go-ipfs stopped finding each other since we got it to work (end of 2015).

It seems that couple of things have changed in go-ipfs, starting with the serviceTag and the really critical change, go-ipfs now squats the host hostname to announce its records through mdns.

See that https://github.com/libp2p/go-libp2p/blob/master/p2p/discovery/mdns.go#L85 passes "" and then https://github.com/whyrusleeping/mdns/blob/master/zone.go#L83-L91

This is the reason why I keep seeing my hostname change when I have an ipfs daemon running:
image

What happens is that (by definition of the mdns protocol), once there is another announcer using the same hostname, one of them has to change.

Unless I'm missing something, I don't see a need to take over the host hostname.

PS: This 'fault' in the protocol is what enabled Watson to hack printers :) https://www.youtube.com/watch?v=BMWP20ZicsY

@daviddias
Copy link
Member Author

@whyrusleeping mind taking a look? I've reached out to @Kubuxu but he was unsure.

@whyrusleeping
Copy link
Contributor

I guess we could try passing the peer ID as the 'hostname' there, that should work right?

@daviddias
Copy link
Member Author

It needs to be a common thing across nodes, otherwise, they won't know whom to query. What about just ipfs.local?

@wigy-opensource-developer
Copy link

wigy-opensource-developer commented Jan 18, 2017

I could imagine people running multiple IPFS nodes in a broadcast domain. Using ipfs.local as the hostname would hurt that use-case. Maybe ipfs-QmBlah.local?

@daviddias
Copy link
Member Author

Back in the 'old days', when ipfs mdns interop worked, this was what go-ipfs used to send as an answer to discovery.ipfs.io.local

   [ { name: 'discovery.ipfs.io.local',
       type: 'PTR',
       class: 1,
       ttl: 120,
       data: 'QmbBHw1Xx9pUpAbrVZUKTPL5Rsph5Q9GQhRvcWVBPFgGtC.discovery.ipfs.io.local' },

     { name: 'QmbBHw1Xx9pUpAbrVZUKTPL5Rsph5Q9GQhRvcWVBPFgGtC.discovery.ipfs.io.local',
       type: 'SRV',
       class: 1,
       ttl: 120,
       data: { priority: 10, weight: 1, port: 4001, target: 'lorien.local' } },

     { name: 'lorien.local',
       type: 'A',
       class: 1,
       ttl: 120,
       data: '127.0.0.1' },

     { name: 'lorien.local',
       type: 'A',
       class: 1,
       ttl: 120,
       data: '127.94.0.1' },

     { name: 'lorien.local',
       type: 'A',
       class: 1,
       ttl: 120,
       data: '172.16.38.224' },

     { name: 'QmbBHw1Xx9pUpAbrVZUKTPL5Rsph5Q9GQhRvcWVBPFgGtC.discovery.ipfs.io.local',
       type: 'TXT',
       class: 1,
       ttl: 120,
       data: 'QmbBHw1Xx9pUpAbrVZUKTPL5Rsph5Q9GQhRvcWVBPFgGtC' } ],

Listening for queries on ipfs.local would be enough, then when replying, we can do -ipfs.local

@whyrusleeping
Copy link
Contributor

wait, if it needs to be common across nodes and we're setting it to os.Hostname currently, how does it work at all?

@daviddias
Copy link
Member Author

It squats it

PS: This 'fault' in the protocol is what enabled Watson to hack printers :) https://www.youtube.com/watch?v=BMWP20ZicsY

@daviddias daviddias added the status/ready Ready to be worked label Jan 19, 2017
@daviddias daviddias added the kind/bug A bug in existing code (including security flaws) label Jan 20, 2017
@ghost
Copy link

ghost commented Jan 30, 2017

@diasdavid how can I reproduce this with js-ipfs? (I'm pretty sure I won't be able to reproduce it on Linux, can't change the hostname as unprivileged user.)

@dignifiedquire
Copy link
Member

any updates on this?

@ghost
Copy link

ghost commented Feb 22, 2017

I had a hard time reproducing it and moved to other things

@daviddias
Copy link
Member Author

@lgierth you should be looking into reproducing it with go-ipfs, that is where I get it to happen, although I'm trying to reproduce it today and it is not happening (or at least not as fast), will continue investigating.

@whyrusleeping whyrusleeping added status/deferred Conscious decision to pause or backlog and removed status/ready Ready to be worked labels Oct 17, 2017
@daviddias
Copy link
Member Author

@richardschneider you have done a lot of work towards fixing mdns in both js and go. Could you share an update here on the current status? Thank you in advance.

@richardschneider
Copy link

https://github.com/libp2p/js-libp2p-mdns now uses ipfs.local as the service tag for the query. The fully qualified server name is Qm...ipfs.local.

There are no resources to work on the GO implementation, https://github.com/libp2p/js-libp2p-mdns.

I'll update the JS readme to give an example query and response.

@daviddias daviddias added help wanted Seeking public contribution on this issue exp/wizard Extensive knowledge (implications, ramifications) required P1 High: Likely tackled by core team if no one steps up labels Jun 2, 2018
@lidel
Copy link
Member

lidel commented Sep 15, 2020

In case someone finds this issue, the latest "mdns" discovery spec is at libp2p/specs/discovery/mdns.md
As I type this both old and new specs are implemented in js-ipfs 0.50, but only old one is supported in go-ipfs 0.7.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/wizard Extensive knowledge (implications, ramifications) required help wanted Seeking public contribution on this issue kind/bug A bug in existing code (including security flaws) P1 High: Likely tackled by core team if no one steps up status/deferred Conscious decision to pause or backlog
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants