debugging network code

[DamageX]

A few years back I wrote a routine that could use WSOCK32 functions to connect to a host and do HTTP GET. So I was able to get network code to function at least to that extent.

Today I tried to make a routine to accept incoming connections. But it would just hang on the call to "accept" and no web browser or telnet client could get it to budge, not locally or from a separate machine. No error codes are returned at any point. I wasted a few hours trying to debug this. Tried various ports. Opened the program in OllyDBG but it is unable to pause the process once the call to "accept" is made and trying to step into it would hang at a certain point.

program flow is like this:
wsastartup
socket
bind
listen
accept

Going back to square one, I modified the seemingly non-working server program into a client program by replacing the call to "bind" with a call to "connect" and verified that this was working. It works. Then I tried using this client to connect to the server. Surprisingly the server accepts the connection. ????

Anybody have any idea why "accept" can take a connection from my own program but not from any other programs?

[MrSwiss]

Anybody have any idea why "accept" can take a connection from my own program but not from any other programs?

Sorry, but without the 'codes' (server and client), there isn't any way to a decent answer ...
(I'm not willing to speculate, without more 'to the point' information.)

Additionally, the 'accept' thingy might just be a 'symptom' but not the initial 'cause'.

[badidea]

Anybody have any idea why "accept" can take a connection from my own program but not from any other programs?

Did you try with 32-bit fbc as well?

[DamageX]

I downloaded this port monitoring program and as soon I ran it I saw the problem. http://www.nirsoft.net/utils/cports.html

(On WinXP or later, NBTSTAT -an reveals similar information)

critical fact: the sockaddr data structure port field uses reverse byte order

[MrSwiss]

critical fact: the sockaddr data structure port field uses reverse byte order

This isn't really news:
network byte order = big endian, AMD/Intel CPU's = little endian (all not network related stuff).

DEMO code:

Code: Select all

' EndianConv-Procs_test1.bas -- (c) 2020-03-05, MrSwiss
'
' compile: -s console (WIN only!)
'

Function Little2Big( _
    ByVal valu As ULongInt _
    ) As ULongInt
    Dim As ULongInt retv
    
    For i As UInteger = 0 To 7
        CPtr(UByte Ptr, @retv)[i] = _
        CPtr(UByte Ptr, @valu)[7 - i]
    Next
    
    Return retv
End Function

Function Big2Little( _
    ByVal valu As ULongInt _
    ) As ULongInt
    Dim As ULongInt retv
    
    For i As UInteger = 0 To 7
        CPtr(UByte Ptr, @retv)[7 - i] = _
        CPtr(UByte Ptr, @valu)[i]
    Next
    
    Return retv
End Function


Dim As ULongInt test = &h001F3F5F7F9FBFDF, bigend, lilend

Print "original (as defined): "; Hex(test, 16), test
Print "little endian: &h"; Hex(test, 16), test
Print "this then means: original = little endian"
Print
Print "convert to big endian ..."
bigend = Little2Big(test)
Print "big endian:    &h"; Hex(bigend, 16), bigend
print
Print "and, back again ..."
lilend = Big2Little(bigend)
Print "little endian: &h"; Hex(lilend, 16), lilend
Print : Print
Print "... done ... ";
Sleep

I've used HEX on purpose, to showcase the difference clearly ...
This is, of course only one of the many ways, to convert big/little endian (e.g. bswap in ASM).