I've noticed a strange thing when dealing with sockets, I always recieve an FD_CONNECT message, even if I'm connecting to a nonsense address.

Is there anyway to check if the connection is actually genuine other than trying to implement some sort of Greeting/Handshaking which would just be plain awkard.
Posted on 2002-08-22 11:22:38 by Eóin
Are you checking for multiple simultaneous FD messages?
And are you checking the ERROR word (high 16 bits of lParam)?

I always like to start my socketmessage handler with something like this...

.elseif uMsg == WM_SOCKET
mov eax, wParam
mov TempSock, eax ;wParam is the hSock which triggered this message
mov eax, lParam ;lParam is the Socket Message Type (FD_BLAH)
push eax

and eax,0FFFF0000h ;Check for possible SocketError code
.if eax!=NULL
shr eax,16
szText szRefused,"Server Refused!"
invoke SendDlgItemMessage,hWnd,502,WM_SETTEXT,0,addr szRefused

Seems that FD_CONNECT is sent to your window not after you have connected per se, but merely if there is a reply of any kind to the TCP SYN packet.
Thus, things like FD_CONNECT+FD_CLOSE are possibilities also.

Don't assume that u will only ever get accept, connect,read and close messages.
You will get combinations !!
FD_READ+FD_CLOSE is a particular problem.
What you should ideally do is either check for specific combinations,
or else filter the value in lParam using AND to check for specific message fields.

mov eax,lParam
.if eax AND FD_CLOSE
........we got at least a close message, maybe more
Posted on 2002-08-24 06:16:51 by Homer
FD_CONNECT is not only called on success, but on error as well. The documentation says:
When one of the nominated network events occurs on the specified socket s, the application's window hWnd receives message wMsg. The wParam argument identifies the socket on which a network event has occurred. The low word of lParam specifies the network event that has occurred. The high word of lParam contains any error code. The error code be any error as defined in WINSOCK.H.

FD_CONNECT is in low-word of lParam, so the error code must be in the high-word of lParam.
Posted on 2002-08-24 11:05:58 by comrade
Thank you guys, I'm sure that would have solved the problem.

However I was getting the feeling that it would be safer to implement the greeting system. What I was doing was having two of my programs talking to each other, so a greeting would be the only way to ensure they were talking to the right program.
Posted on 2002-08-25 16:43:52 by Eóin
You can have a look in the client/server example I posted in this forum for an example of application protocol handshaking.
It's completely up to you how your programs interact with one another.
For example, I have removed the initial server greeting now,
so the server remains silent when a new client connects. If the client doesn't send the right thing in its first data packet, the server will terminate its connection on the spot. This technique makes scanning for known services more difficult for a possible attacker.
There's basically two schools of thought here:
#1 text-based protocols (like msn, smtp/pop3, http, ftp etc etc) and
#2 structured protocols (like yahoo!, RTP, etc)

Text-based protocols rely heavily on the notion of "delimiters" which separate the fields of data within each payload.

Structured protocols simply store the data in an expected format, using fields of a data structure to keep everything orderly.They can therefore do away with the notion of delimiters as such.

Inventing your own protocols is probably the most satisfying thing you could do with your network-coding time :alright:
Posted on 2002-08-30 00:15:51 by Homer
Attacks won't be a problem, I doubt there'll be more than 4 copies of this program floating around at anyone time :) .

Also I'm slightly more worried about a client connecting to an invalid computer, rather than a accepting an invalid connection so I'll keep the dual greeting.

Posted on 2002-08-30 07:44:20 by Eóin