30 May
2017
30 May
'17
1:45 a.m.
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.