network connection printer down

[Rashid Hamid]

We always experience connection printer down. When this happen the users will not be able to use the remote printer.
They can only use the network printer. The network printer can still be used if the connection printer down happens.
If we do a lpstat -t command there will be a lot of connection printer down message appear. For the remote printer we use the omniprint software at the client side. If we ping to the remote printer the network is still alive. When we check using the command below:
# netstat -an|grep FIN_WAIT_2|wc -l
The figure will be around 499. This is what we notice. If it is less than 499 the connection printer down won't happen.

Appreciate your help on the above problem.
Thanks for helping.

[Niel Greeff_1]

Sounds like a problem we had.

Our network was shared with Novell Netware. Novell has the worst "noise" on a network.
The fix was to configure switches not to allow SNMP from Novell servers (unless they are print servers). Later we separated Novell and UNIX on the network. The UNIX network (HP, SUN, Digital, Linux, SCO) runs at least twice the speed of the Novell one.

[George_Dodds]

what type of printer is it and does it have any power saving settings?

Cheers

George

[Stefan Farrelly]

When a network connection starts to go down, hand-shaking occurs to ensure that both sides have completely cleaned up the connection. When the HP gets a connection close request from a outside source, it will begin to shutdown the connection. To see if the other side is ready to proceed with the close, it sends a FIN packet to the other end and waits for a FIN_ACK. While waiting for this packet, the system will show the connection in a FIN_WAIT_1 state.

Once this first FIN_ACK is received, the system will shut more of the connection down and just before everything closes, it will send a second FIN packet to the other side and wait for another FIN_ACK. While waiting, connections will be reported in the FIN_WAIT_2 state. In either of these state, nothing can be done to the connection. By default, the system will wait indefinitely for the FIN_ACKs because it wants to ensure that the other side of the connection closes cleanly.

So, you need to modify some TCP settings in order to get around the large number of FIN_WAIT_2 connections you have. Heres what to add into your /etc/rc.config.d/nddconf file;

TRANSPORT_NAME[0]=tcp
NDD_NAME[0]=tcp_ip_abort_interval
NDD_VALUE[0]=30000

TRANSPORT_NAME[1]=tcp
NDD_NAME[1]=tcp_ip_abort_cinterval
NDD_VALUE[1]=15000

TRANSPORT_NAME[2]=tcp
NDD_NAME[2]=tcp_fin_wait_2_timeout
NDD_VALUE[2]=15000

Add these to the nddconf file, reboot, and now you shouldnt get anywhere as many FIN_WAIT_2 connections.

There is also a script to kill sockets stuck in FIN_WAIT_2 but its possibly risky and its much better to prevent them in the first place than kill them once theyre created.

[Ron Kinner]

Do you have any NT boxes involved in this mess? There is a bug even in NT SP6A in the TCP/IP stack that forgets to resend an unacknowledged FIN. I have the fix from Microsoft if you need it.

Ron