search

balena-io / balena-cli

The official balena CLI tool.
Apache License 2.0
452 stars 138 forks source link

`balena scan` does not always return all balenaOS development devices #940

Open hedss opened 6 years ago

hedss commented 6 years ago

It's been discovered that Avahi is occasionally not returning all the records required for device/service discovery. This is because only PTR records are being returned, instead of PTR/SRV/A/AAAA.

See resin-io/hq#1434 for further technical details.

Our options are probably either to debug and patch Avahi (probably tricky), or to add some extra safeguarding in our forked version of resin-io/bonjour which note when only PTR records are returned and specifically ask for SRV/A/AAAA records as well. This should force Avahi to return them correctly and for us to be able to retrieve the information required to pass the device details up.

hedss commented 6 years ago

The root cause is this: https://github.com/lathiat/avahi/issues/7 It's probably going to make it into 0.8 (I hope): https://github.com/lathiat/avahi/milestone/3

Short-term fix: In resin-io/bonjour self-generate SRV record based on returned PTR (though we are forced to assume port 22222), then request A/AAAA records appropriately for the target domain

drjasonharrison-vp-eio commented 5 years ago

An alternative when resin local scan fails is to use arp-scan https://github.com/royhills/arp-scan

Avahi 0.8 is now a year overdue: https://github.com/lathiat/avahi/milestone/3

pdcastro commented 5 years ago

Connects to:

pdcastro commented 4 years ago

I think the description of issue #542 could be useful here.

hedss commented 4 years ago

There's actually another issue I've seen on a development board today which is where Avahi continually believes it's already published a conflicting hostname: https://github.com/lathiat/avahi/issues/117

This has been open for ages, it's still not fixed and I don't think it ever will be, so we may have to try and guard against it in the OS.