On 09/04/98 00:12:22 you wrote:
I thought this follow-up (to a thread from several months ago) might be interesting for people at sites that stress time synchronization.
Daniel Quinlan quinlan@transmeta.com wrote:
To prevent it from happening again, we're remotely monitoring the system time of the adminhost (using "mon") to make sure it doesn't drift off again. Incidentally, there seems to be no way to remotely query the system time from a NetApp (except by creating a new file and running stat() on it, or by using unsupported/hidden commands).
So, I started monitoring the time with the kludgey method of creating a file and using stat() on it. I wasn't very happy with that method because it tended to give false alerts, so I eventually disabled it.
Earlier this week, we had another problem with time synchronization. It wasn't actually the NetApp, but I still had to rule it out because it wasn't being monitored. I tried port-scanning a NetApp, looking for some hidden protocol that might let me reliably query the time. Here's what I found:
port tcp udp
23 telnet - 80 http -111 sunrpc sunrpc 137 - netbios-ns 138 - netbios-dgm 139 netbios-ssn - 161 - snmp 514 shell syslog 520 - route 602 - unknown 603 unknown - 604 - unknown 605 unknown - 606 - unknown 607 unknown - 608 - unknown 609 unknown - 618 - unknown 619 - unknown 620 unknown - 1063 - unknown 2049 nfs nfs 10000 unknown -
A lot of unknown services (ones not listed in /etc/services, some are probably NDMP.
I thought the 600 ports were for rsh, but by they alternate between TCP and UDP, and aren't contiguous, I don't know.
I have no idea what 10000 is for.
Bruce