🚀 go-pugleaf

"Boguslaw Fries" <B.Fries@luca-online.de> wrote in message
news:3e68956a@newsgroups.borland.com...

> If I have a pointer to a opened Socket, could I
> find the information about Remote address and
> Remote Port?

Use getpeername() for that.  The sockaddr structure is filled in with
information about the remote end of the connection.

> Local Address and Local Port is simple:
<snip>

Use getsockname() instead of getsockopt().


Gambit

I did it

SOCKADDR_IN name;
SOCKADDR_IN speer;

getsockname( s, ( SOCKADDR *) &name, &namelen ) gives proper resulsts ( it
doeas mena local address and port  )
but
getpeername( s ( SOCKADDR * ) & speer, &namelen ) gives SOCKET_ERROR
and WSAGetLastError  gives 10057


Boguslaw Fries

Boguslaw Fries wrote:

> getpeername( s ( SOCKADDR * ) & speer, &namelen ) gives SOCKET_ERROR
> and WSAGetLastError  gives 10057

Error 10057 means socket not connected. Are you properly connected to 
your peer address? Do you use connect() before using getpeername():

SOCKET s=socket(AF_INET,SOCK_STREAM,0);
...
connect(s,(sockaddr*)&speer,sizeof(SOCKADDR_IN));
getpeername(s,(sockaddr*)&speer,&namelen);

Michel
-- 
----------------------------------------
Michel Leunen
mailto:michel@leunen.com
http://www.leunen.com/cbuilder/
----------------------------------------

Problem is more cmplicated
I wrote a program which read all socket from the system and I displaz the
results
something like netstat -a but with process names

so shortly I got socket pointer from NtQuerySystemInformation
using DuplicateHandle I enumerate the sockets and finally make getsocktename
and socketpeer names
socket names are correct BUT CONNECTED socket are not!!!

Best regards
Boguslaw Fries

"Boguslaw Fries" <B.Fries@luca-online.de> wrote in message
news:3e69dbad@newsgroups.borland.com...

> so shortly I got socket pointer from NtQuerySystemInformation

How exactly?  Looking at the documentaton and declarations for
NtQuerySystemInformation() and its structures, I see nothing that returns
socket-related information at all.

> using DuplicateHandle

Sockets are not kernel process objects.  You can't duplicate them using
kernel functions.  I'm surprised DuplicateHandle() would do anything at all.

What does your EXACT code look like?


Gambit

ok, I write

hCurrentProcess = GetCurrentProcess( );
OpenProcessToken(  hCurrentProcess, TOKEN_QUERY | TOKEN:ADJUST_PRIVILEGES,
&hToken );
SetPrivilege( hToken, SE_DEBUG_NAME, true );
NtQuerySystemInformation( SystemHandleInformation, lpSystemInformation,
dwlength, &dwreturnlength );

....
lpSystemHandle = ( LPSYSTEM_HANDLE ) lpSystemInformation->systemHandles;

for( dwCount = 0; dwCount < lpSystemInformation->dwNumEntries; dwCount ++ )
 {
       hDup = NULL;
        hproc = openP1ocess( PROCESS_DUP_HANDLE, 1,
lpSystemHandle->dwProcessId );
       if( hproc )
        {
            DuplicateHandle( hproc, ( HANDLE ) lpSystemHandle ->uhandle,
hCurrentProcess, &hDup, STANDARD_RIGHTS_REQUIRED, false, 0);
        if ( hdup )
        {
            s = ( SOCKET ) hDup;
            nRet = getsockname( s, ( SOCKADDR * ) & name &namelen );
            ...

        }
        }
}


As above is a part of my code
    name has alway proper information about socket name and address --
socket s
but     getsockopt returns false protocol type of this socket ( always UDP )
    and getpeername always fails wit 10057

thanks for your patience

Boguslaw Fries

"Boguslaw Fries" <B.Fries@luca-online.de> wrote in message
news:3e6a7d78$2@newsgroups.borland.com...
> ok, I write
<snip>

Your code sample is incomplete.  What is lpSystemInformation declared as?
What is a SYSTEM_HANDLE?  SYSTEM_HANDLE is not documented by Microsoft.  And
SystemHandleInformation is not listed in NtQuerySystemInformation's supposed
classes.

In any case, your code is only dealing in process handles, as far as I can
tell.  A process handle is not a socket handle.  They are completey
different things from completely different libraries.  Even in the
off-chance that NtQuerySystemInformation() does return socket handles as
well, based on the documentation I was able to find elsewhere, you should be
using the SYSTEM_HANDLE's ObjectType member to see what the actual type of
handle is being reported.  Right now, you're assuming every handle is a
socket handle, which is not the case.  The OS has many different kinds of
handles available.


Gambit

typedef struct _SYSTEM_HANDLE
{
dword dwprocessid,
byte bObjType,
Byte gFlags,
ushort uHandle,
dword pObject,
ulong Grantedaccess;
}
SYSTEM_HANDLE;

typedef struct _SSTEM
{
      dword dwNumEntries;
        SYSTEM_HANDLE systemHandles[ ANY_SIZE]  ;

}SYSTEM_HANDLE_INFORMATION;