Dear Socks5 Community!

Recently I submitted a detailed (and long) bugreport (including fixes)
of some socks5 server bugs to the socks5 ref-impl. maintainer.

I want to give a short outline of the bugreport here.

The full bugreport and patches can be downloaded from

	http://jk.kom.tuwien.ac.at/Software/socks5/


1. Unexpected termination of the server with "fork failed" message.

Symptoms:

Socks-log shows something like that:
Nov  3 18:06:30 dax Socks5[24817]: 000001: server exiting: fork failed
Nov  3 18:06:31 dax Socks5[24817]: 000001: Socks5 Exiting at: Fri Nov 03 18:06:30 2000

Versions: socks-1.0r10, socks-1.0r11 (probably other versions since 1.0r5 too).
Plattforms: all
Operational mode: probably only in threaded mode (-t)
Environment:
	Observed,  analysed,  fixed  and  tested  on   a   Solaris   2.6
	environment; server started with default parameters in  threaded
	mode. The system is heavy-loaded.
Description: Above termination message comes from a delayed error in
	signal handling.


Fixed: See the URL given above. The fix includes in addition a improved
	thread management, which prevents a starvation effect because of
	the limit on creatable processes.


2. Termination of the main acceptor process, leaving some client
	processes which are not able to accept new connections.

Versions: only socks-1.0r11, so far.
Plattforms: at least Solaris 2.6, probably in most Unix-based
	ennvironment.
Operational mode: at least in threaded mode (-t)
Environment:
	Observed, analysed, fixed and tested on a Solaris 2.6
	environment; server started with default parameters in threaded
	mode. Connection rate must by high enough.
Description:
	The signal setup flags which are inappropriate for most Sys5-
	based environments are simply wrong (mimics unsafe behavior of
	some BSD-style system). The acceptor process terminates and some
	client processes will remain active.
Fixed:
	See the URL given above. The signal() behavior is set back to the
	common Sys5-signal handling, which otherwise let the acceptor
	process terminate unexpectly.

Since these fixes has been applied our server runs stable without any
obviously problems.

I hope, this could be helpful to some people and the fixes are
merged into the official distribution some days.


Johann K.

-- 
Johann E. Klasek      Zentraler Informatikdienst - Kommunikation
Technische Universität Wien               Tel: +43 1 58801-42049
A-1040 Wien, Wiedner Hauptstr. 8-10/020C  Fax: +43 1 58801-42099
<a href="http://pgpkeys.tuwien.ac.at:11371/">PGP Key jklasek</a>