Joe,

Which version of Sesame do you have?

Are you using a sesame_allow or sesame_deny file?

They are optional. You do not have to use them. I am asking because there was a bug in the Unix version in association with these files that I recently fixed.

Can you tell me a little bit about the client and the server? First - are they the same computer? If not, are they running the same OS? If not, can you identify which OSs are being run? Also, on the Linux server are you using a "hosts" file (/etc/hosts) or are you using DNS, or other name server, or both? When you connect, are you using the name of the server or its IP address? I.E.:

sesame -client MyServer:20020:20021

or

sesame -client 192.168.0.20:20020:20021

I am asking because, crashing just as a client connects on a Linux computer is usually caused by a bug (since found and fixed) in name resolution, when the server side of sesame is trying to determine the human readable name of the client computer from its IP address.

In any case, have you considered upgrading to 1.0.4?

I just tried it with Sesame 1.0.4 running on Red Hat 7.3 with a Sesame client running in Win2000 running Sesame 1.0.3 - using the default ports (20000 and 20001). It connected and ran well.

Tomorrow I will try Sesame 1.0.3 on the server. I will also try it on the latest version of Suse Linux with 1.0.3.

Ray brought up an interesting point - is there a gatekeeper of any kind (such as IP chaining) on the ports you are using?

What *may* be happening has to do with the sequence of events that occur when a client connects. The server issues a challenge to the client to make sure that it is a Sesame client. Soon afterwards the server resolves the client name from the connecting IP address. In the code that resolves the IP address there was a possibility that the OS would return a failure the first time it was asked because the communication is asynchronous. The code was not prepared for this failure and was using the now incorrect return value. I put in a error check to determine if that failure occurred. It only occurs if the timing is just so. So, to test it, I have to force the connection timing, it does not occur on most boxes or OSs. It was first seen on WinXP, as is noted in the 1.0.4 change log. But the fix applies to all OSs.