I have observed a problem with a PM-3 Com/OS 3.7.2c3. Although not being
able to reproduce this bug myself just now I think it's a possible
concern. A coworker of mine has confirmed this as well with 3.7.2c2.
Basically, while in contact with lucent concerning a bad Portmaster
that has reported many violations and alarms, I encountered the problem
that some network connections were showing ESTABLISHED while they really
weren't, this caused the PM not to accept any new connections after 1
connection. Not sure what's up with the ESTABLISHED connections that
weren't really true, but the other was fine all one needs to do is use the
documented command to increase netconnections. I then proceeded to do
this, although something I did did not allow me to reach more connections
to the administrative port. So I decided to reset these bogus connections
with the documented command "reset n{handle}". Let me paste some text
that I saved at the time this happened.
<paste from previous mail - *shadow* == shadowed hostname,
xxx.xxx.xxx.xxx == shadowed IP quads>
Date: Mon, 15 Jun 1998 18:19:54 -0400 (EDT)
From: Peter Philipp 99 <philipp@globalserve.net>
Subject: ** shadowed **
*shadow*> show netconns
Hnd Recv-Q Send-Q Local Address Foreign Address (state)
84 0 2 *shadow*.globalserv.xxxx *shadow*.globals.2925
ESTABLISHED
529 0 0 *shadow*.globalserv.1643 0.0.0.0.0
LISTEN
526 0 0 *shadow*.globalserv.1401 *shadow*.globalserve.53
UDP
627 0 0 *shadow*.globalserv.xxxx *shadow*.globalser.3980
ESTABLISHED
641 0 0 *shadow*.globalserv.xxxx *shadow*.globalser.2608
ESTABLISHED
699 0 0 *shadow*.globalserv.1023 *shadow*.globalserve.514
UDP
267 0 0 *shadow*.globalserv.xxxx *shadow*.globalser.3073
ESTABLISHED
10 0 0 *shadow*.globalserv.67 0.0.0.0.0 UDP
6 0 0 *shadow*.globalserv.161 *shadow*.globals.46763 UDP
5 0 0 *shadow*.globalserv.1649 xxx.xxx.xxx.xxx.1649
UDP
4 0 0 *shadow*.globalserv.1026 *shadow*.globalserv.1646
UDP
1 0 0 *shadow*.globalserv.520 xxx.xxx.xxx.xxx.520
UDP
*shadow*> reset n627
Network connection 627 successfully reset.
*shadow*> reset n641
Network connection 641 successfully reset.
*shadow*> show netconns
Connection closed by foreign host.
*shadow* % telnet *shadow* xxxx
Trying xxx.xxx.xxx.xxx...
Connected to *shadow*.globalserve.net.
Escape character is '^]'.
ComOS - Livingston PortMaster
login: !root
Password:
*shadow*> ver
Livingston PortMaster PM-3 ComOS 3.7.2c3
System uptime is 0 minutes
</end paste>
The box crashed after a 93+ day uptime. Now the two connections I reset have
been lingering in the ESTABLISHED state for a while (noticed 2 days ago).
I hope someone can reproduce this on their own PM with COM/OS 3.7.2c3 so
that we have a case. Meanwhile I tend to think there might be a runaway
pointer somewhere in the netconns/network code that is not obvious until a
very high uptime has reached (after many many connections to the console
port).
Please direct positive feedback to the list.
Peter Philipp (PP2441)
Daemonic Networks
"How I wish you were here..." - Pink Floyd
-
To unsubscribe, email 'majordomo@livingston.com' with
'unsubscribe portmaster-users' in the body of the message.
Searchable list archive: <URL:http://www.livingston.com/Tech/archive/>