Well, what I wrote does this:
68.100.10.100 44.62.5.1 5678 MikroTik 6.36.1 (stable) MikroTik 5RRB-VMWG RB750Gr3 UCSD 84.106.126.184 44.137.1.92 5678 MikroTik 6.38.5 (stable) MikroTik V2P4-7CQK RB2011UiAS-2HnD ucsd-gw
As far as MikroTik router gateways go, that's pretty much all there is to be learned from the MNDP broadcasts. - Brian
On Tue, May 30, 2017 at 08:26:13AM +0300, Marius Petrescu wrote:
That's true. The intent of those packets was to allow device discovery for their configuration utility, and never leave the local network (as any broadcast btw).
If we really want a tracking/monitoring tool, we should check our requirements and write the proper tool. As Lynwood suggested, such component could be included in the ampr-ripd and ampr daemons, or created as a standalone tool, to allow some kind of client announcement/registration (e.g. as a JSON content including elements such callsign, serviced subnets or others).
If we really need such thing is another question.
Marius On 30.05.2017 06:09, Brian Kantor wrote:
If I hadn't already written it, I'd question the value of a daemon gathering that data....
- Brian
On Tue, May 30, 2017 at 06:04:51AM +0300, Marius Petrescu wrote:
You can actually see the router model, router ID, interface name, and uptime.