We should make some tooling for mDNS/local nerves devices

Nerves Forum Nerves Chat
1

Half the problems of figuring out if a device is up during dev is about figuring out if a device came up and with what hostnames?

For pis you get nerves.local or whatever you set plus a nerves-1234.local. When juggling devices you sometimes get collisions, sometimes you unwittingly switch hostname.

I guess we could do a mix command to check mDNS info locally. Would need some different implementation between platforms but…

Good idea?

3 Likes
2

I’ve been using ‎Discovery - DNS-SD Browser on the Mac App Store on mac to browse mDNS data.

Wouldn’t mdns-lite be able to handle that?

4 Likes
3

I know mdns-lite can do it on Linux because I have used it for that. I don’t am not sure if the story is the same on other platforms…

4

Given there’s no C code I’d naively expect it to work cross platform. By my understanding it’s UDP/TCP underneight mDNS, which should just work on the beam.

1 Like
5

That makes some sense. I’ve mostly used mdns_lite with Nerves and VintageNet and VintageNet needs Linux.

Travelling now but want to try this.

6

@fhunleth what do you think about mix upload maybe checking what appropriate mdns hosts are around and listing them if no hostname is given?

If only one shows up it could try that one as long as it indicates clearly it is going for that particular one. I asusme the current logic is default to nerves.local?

7

I definitely think easier and better device discovery would be super helpful to anyone using Nerves.

As for mDNS (or SSDP which some people have used with Nerves too), I’ve gotten a little discouraged with Elixir-based CLI tool usage. The main reason being that ideally the tools would query the system responders and there’s no cross-platform API. Starting a new responder (e.g., using mdns_lite on MacOS) conflicts the the system one and can lead to surprises - like the system and CLI are out of sync.

If I could propose an alternative strategy and that’s to implement a really simple discovery protocol that won’t conflict with existing responders, doesn’t do any caching, doesn’t use a privileged port number, and can be implemented in pure Elixir. I haven’t done a review of all that’s out there, but the Mikrotik Neighbor Discovery Protocol seems like it could be made to work really well. Wireshark decodes it so debugging would be easier.

2 Likes
8

Super useful input :slight_smile:

9

Hey @fhunleth

i’ve read your post and felt motivated to start something.

I have some MikroTik devices lying around and started a new library

There is still some work to do, but i can successfully parse the discovery packet of my MikroTik router.

What would be needed to make this useful in Nerves?

I would imagine:

  • a gen server which sends the discovery packets in an interval so we could start it in the application tree of the nerves device
  • a mix task to listen to these discovery packets and display them in the CLI
7 Likes
10

This is awesome! Spitballing off the top of my head, some useful things might be:

  • GenServer that is watching for these packets on a specific interface
  • Being able to subscribe to these packets from another process (rather than an interval send)
  • Sending a discovery packet for another device to see

This is basically caching so maybe stretch goals:

  • keeping a history of found devices
  • Being able to query the list of found devices and their most recent packet
1 Like
11

Nice! All I want to do is to be able to find Nerves devices reliably. This seems like a great step in that direction.

2 Likes
12

Brief update:

I’ve added a Listener GenServer with a custom callback. It looks like this:

MNDP.Listener.start_link(fn mndp -> IO.inspect(mndp) end)

Currenty the UDP socket is opening on 0.0.0.0 so that i can receive packets from all interfaces.

I’ve also added error handling to the parsing and did extensive research about the header values. It’s still unclear and i think the values changes from Version 6 to 7 because i have a device with each version and the sequence number is represented by different bytes. Unfortunately there is no official spec for the headers and some of the fields are unclear. Even the Wireshark dissector has no clue

TODO:

  • Find out about first 4 bytes
  • Find out about additional TLVs
  • Find out about unpack values

Next i will add functionality to broadcast your own discovery packet!

2 Likes
13

Following this excitedly :slight_smile:

1 Like
14

Official MikoTik Tool WinBox recognizes the packets!

WinBox Screenshot
WinBox Screenshot875×124 5.48 KB

Code is still messy but i tried to make it work at first. Next i’m working on fixing that :slight_smile:

4 Likes
15

Woohoo!

16

i’ve opened a seperate topic for the library. See MNDP - Mikrotik Device Discovery Protocol