@dadude: "I have two ultrasparc machines running solaris 2.5.1.  On these two
boxes, I need to monitor port 102.  As long as traffic is being
received, everything's ok.  But if traffic stops coming into port 102, it
needs to send a notification. Something like snoop, piped to an alerting
program would work, but be nice to have something a little more elegant,
and something I could daemonize.
Thanks in advance!"
    @vilain: "<quote>
AFAIK, if something's already listening on that port, you can't open it 
with another application.  So, if that deamon/application dies, a 
monitor scanning for "expected processes" running continuously and 
sleeping or running periodically in cron could do whatever type of 
notification you want.
DeeDee, don't press that button!  DeeDee!  NO!  Dee..."
    @dadude: "But how to tell if there's incoming traffic.  The daemon can be listening
and ok, just there's nothing coming in.  That's the situation I want to
check for.
Thanks!
<quote>"
    @vilain: "<quote>
[top posting fixedsee <url>
Detecting traffic or lack thereof on a port is totally up to the 
application or daemon that's listening to the port.  If it doesn't do 
that, then you need to rewrite it to have traffic detection thresholds.  
Or ask the vendor to enhance it.  If you give most vendors enough money, 
they'll bend over backwards (or forwards).
If you can't enhance the daemon, you could use snoop with associated 
directives to look at the traffic on that port occasionally, but it 
opens the NIC in promiscuous mode.  That's a performance hit and not 
recommended for long-term use.  See the snoop man page.  For large 
volumes of data, this is _NOT_ recommended.  snoop is a network 
debugging tool.
You could also start looking at external network monitoring hardware to 
put between the systems and their hub (e.g. a PC sniffer).  Or perhaps 
your hub or router has some smarts that could do SNMP traps if traffic 
to that port on the network segment drops below a threshold.  Then 
HP/Openview or other network monitoring software could catch that trap 
and page you.  This would be the route I'd go.
Or rethink this approach entirely.  And whack the PHB with a 
ClueByFour(tm) that asked for it.
DeeDee, don't press that button!  DeeDee!  NO!  Dee..."
    @juhan: "<quote>
BTW, I've experienced a possibly similar situation in the past, years
ago with a defective OS/2 SNA middleware product. You can't always get the
vendor(s) support, esp. if vendors are pointing fingers at each other.
What about writing (adapting?) some kind of "wrapper" to forward traffic
from one port to another (the one to be used by the service), and do
monitoring and reporting as it sees traffic go by? Shouldn't be too hard?
Juhan Leemet
Logicognosis, Inc."
{'source': 'USENET', 'other_information': '{"reply_count": 4, "forum_name": "comp.sys.sun.hardware.20141226.mbox"}', 'file': 'data/output/usenet-comp.sys.parquet'}