TSP: intercepting "WSPConnect": value of "name" parameter always "0.0.0.0"? - Programmer

This is a discussion on TSP: intercepting "WSPConnect": value of "name" parameter always "0.0.0.0"? - Programmer ; Hello, using the Microsoft TSP-example and intercepting "WSPConnect" (see code snippet below), I found that I would always get "0.0.0.0" and some random port for the local and remote endpoints. Shouldn't the "name" parameter of "WSPConnect" contain the actual remote ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: TSP: intercepting "WSPConnect": value of "name" parameter always "0.0.0.0"?

  1. TSP: intercepting "WSPConnect": value of "name" parameter always "0.0.0.0"?

    Hello,

    using the Microsoft TSP-example and intercepting "WSPConnect" (see
    code snippet below), I found that I would always get "0.0.0.0" and
    some random port for the local and remote endpoints.
    Shouldn't the "name" parameter of "WSPConnect" contain the actual
    remote IP endpoint to which the user application is connecting to?

    ----8<-------------

    SOCKADDR_IN localAddr;
    SOCKADDR_IN *pRemAddr = (SOCKADDR_IN *)name;
    int sockAddrLen = sizeof(SOCKADDR_IN);
    getsockname(SocketContext->ProviderSocket, (SOCKADDR *)&localAddr,
    &sockAddrLen);
    dbgprint("WSPConnect: %s:%d -> %s:%d",
    inet_ntoa(localAddr.sin_addr), localAddr.sin_port,
    inet_ntoa(pRemAddr->sin_addr), pRemAddr->sin_port);

    ----8<-------------

    best regards,
    Johannes Resch

  2. Re: TSP: intercepting "WSPConnect": value of "name" parameter always "0.0.0.0"?

    Update: the issue regarding port numbers has - of course - been
    because of network vs. host byte order..stupid me.

    However, "inet_ntoa(pRemAddr->sin_addr)" still returns "0.0.0.0"
    instead of the actual remote IP address connecting to.

    In short, the relevant code is:

    ---------------------
    SOCKADDR_IN FAR *pRemAddr = (SOCKADDR_IN FAR *)name;
    inet_ntoa(pRemAddr->sin_addr);
    ---------------------
    ("name" is the parameter "const struct sockaddr FAR * name" from
    WSPConnect)

    Any ideas what's wrong here?

    The Winsock SDK doc says, that the string returned by "inet_ntoa" is
    only guaranteed to be valid until the next Winsock-API call, so I
    tried copying the string locally. That didn't seem to be the problem,
    though.

    Any comments are appreciated,

    best regards,
    Johannes Resch


    jr@xor.at (Johannes Resch) wrote in message news:...
    > Hello,
    >
    > using the Microsoft TSP-example and intercepting "WSPConnect" (see
    > code snippet below), I found that I would always get "0.0.0.0" and
    > some random port for the local and remote endpoints.
    > Shouldn't the "name" parameter of "WSPConnect" contain the actual
    > remote IP endpoint to which the user application is connecting to?
    >
    > ----8<-------------
    >
    > SOCKADDR_IN localAddr;
    > SOCKADDR_IN *pRemAddr = (SOCKADDR_IN *)name;
    > int sockAddrLen = sizeof(SOCKADDR_IN);
    > getsockname(SocketContext->ProviderSocket, (SOCKADDR *)&localAddr,
    > &sockAddrLen);
    > dbgprint("WSPConnect: %s:%d -> %s:%d",
    > inet_ntoa(localAddr.sin_addr), localAddr.sin_port,
    > inet_ntoa(pRemAddr->sin_addr), pRemAddr->sin_port);
    >
    > ----8<-------------
    >
    > best regards,
    > Johannes Resch


  3. Re: TSP: intercepting "WSPConnect": value of "name" parameter always "0.0.0.0"?

    In article , jr@xor.at
    (Johannes Resch) wrote:
    >Update: the issue regarding port numbers has - of course - been
    >because of network vs. host byte order..stupid me.
    >
    >However, "inet_ntoa(pRemAddr->sin_addr)" still returns "0.0.0.0"
    >instead of the actual remote IP address connecting to.

    ...
    >> dbgprint("WSPConnect: %s:%d -> %s:%d",
    >> inet_ntoa(localAddr.sin_addr), localAddr.sin_port,
    >> inet_ntoa(pRemAddr->sin_addr), pRemAddr->sin_port);


    As a quick note to those following here, but not on the Winsock 2 mailing
    list, this turned out to be a problem with the way that inet_ntoa uses one
    static buffer. Essentially, code such as the above (watch for macros that
    might generate that kind of code!) will result in the buffer from one of the
    inet_ntoa calls being printed twice.

    Copy data out of static buffers before calling the function that uses them.

    Alun.
    ~~~~

    [Please don't email posters, if a Usenet response is appropriate.]
    --
    Texas Imperial Software | Find us at http://www.wftpd.com or email
    1602 Harvest Moon Place | alun@texis.com.
    Cedar Park TX 78613-1419 | WFTPD, WFTPD Pro are Windows FTP servers.
    Fax/Voice +1(512)258-9858 | Try our NEW client software, WFTPD Explorer.

+ Reply to Thread