On the PM3, the "show netcon" command also shows that the Recv-Q
value for the locked up connection is 3072.
On the Unix side (the system from which I launched the "attack"),
the socket has a Send-Q size of 6419, and is in the state "FIN_WAIT_1".
When I kill off the telnet process, the socket does not get closed
down completely (as I previously thought), but rather stays in the
state "FIN_WAIT_1". Things will stay in that condition until a "reset n###"
command is given on the PM3, at which time the Unix side goes into the
"CLOSING" state, where it stays for a few minutes before going away.
The Unix system in question was running FreeBSD 2.2.6.
As was pointed out to me privately, another way to get access to
the PM3 to reset the connection is to dial into the unit, log in
as !root, and then give the appropriate "reset n###" commands.
Assuming you can dial into the affected PM3 (i.e., not one of many
PMs on a single number, and there is an available modem/session),
this is another viable recovery method.
-- Michael Bryan michael@blueneptune.com - 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/>