@ping: response code, data size and documentation incorrect

[thorsten]

Latest TCC 13

echo %@ping[8.8.8.8,1,n] (for different values of n):

0 <= n <= 8: Wireshark shows that the data (payload) sent is actually 60 bytes (the overall size of the echo request packet "on the wire" is 60 + 42 = 102 bytes).

9 <= n < =11: Wireshark shows that the data (payload) sent is actually n - 4 bytes. The return code is -1 ("time out") indicating an error although Wireshark shows the echo reply is received.

12 <= n: Wireshark shows that the data (payload) sent is actually n - 4 bytes (the return code is now correct).

Suggestions: make @ping consistent with Windows' ping (-l size) - preferably allowing data sizes starting from 0 and default to 32. Update documentation's "packetsize defaults to 64 bytes. The minimum packet size is 8 bytes" to "data size defaults to 60 bytes. The minimum data size is 5 bytes".

 

[vefatica]

On Sat, 08 Oct 2011 10:32:06 -0400, thorsten <> wrote:

|echo %@ping[8.8.8.8,1,n] (for different values of n):
|
|0 <= n <= 8: Wireshark shows that the data (payload) sent is actually 60 bytes (the overall size of the echo request packet "on the wire" is 60 + 42 = 102 bytes).
|
|9 <= n < =11: Wireshark shows that the data (payload) sent is actually n - 4 bytes. The return code is -1 ("time out") indicating an error although Wireshark shows the echo reply is received.
|
|12 <= n: Wireshark shows that the data (payload) sent is actually n - 4 bytes (the return code is now correct).

If that's the "length" as specified by the sniffer, it's quite likely that
includes an 8-byte header and the actual payloads agree with mine.

Apparently, asterisks (*) are used for the payload. When I watch with windump,
and specify sizes "0 to 96 by 4" I get (below, specified size/actual payload
(i.e., number of asterisks)).

0 / 52
4 / 52
8 / 52
12 / 0
16 / 4

From there on the pattern continues; I get a payload equal to the specified size
minus 12.

Like you, I **ALWAYS** get a timeout when the specified size is 9, 10, or 11
(very strange!) ... with any target host.

v:\> do i=0 to 12 (echo %i  %@ping[localhost,1,%i] & delay 1)
0  1
1  0
2  0
3  1
4  1
5  0
6  0
7  0
8  1
9  -1
10  -1
11  -1
12  0

So there would seem to be the two issues you pointed out: (1) size not as
specified by the user, and (2) timeout with sizes 9, 10, 11.

Note: TCC is, to a great extent, at the mercy of the IPWorks software it uses.

If you have my SYSUTILS plugin or care to get it (ftp://lucky.syr.edu/4plugins)
try @ICMP[]. It gives the specified size (except for size 0, which results in
the default 32).

 

[vefatica]

I wrote:

So there would seem to be the two issues you pointed out: (1) size not as specified by the user, and (2) timeout with sizes 9, 10, 11.

Add to that (3) small sizes not coherent with bigger ones.

I did some snooping and found that IPWorks loads ICMP.DLL and uses the same three functions that I use (see below) in @ICMP[]. I don't know what IPWorks is doing but when using IcmpSendEcho, there's no trick to getting the data size, as specified by the user, correct ... any number from 0 up (I cut it off at 1460). So, Rex, if you're going to look into this, maybe the code below will give some insight. Is assumes you already have an in_addr; timeout is in milliseconds; 0 LE datasize LE 1460.

<ipexport.h><icmpapi.h>INT ping ( in_addr address, DWORD dwTimeout, WORD wDataSize)
{
    DWORD    rv = -3,
            dwBufferSize = wDataSize + sizeof(ICMP_ECHO_REPLY);

    LPBYTE pOutData = (LPBYTE) AllocMem(dwBufferSize);
    FillMemory(pOutData, wDataSize, '*');

    PICMP_ECHO_REPLY pReply = (PICMP_ECHO_REPLY) ((LPBYTE) pOutData + wDataSize);

    HANDLE hIcmp = IcmpCreateFile();

    if ( 0 == IcmpSendEcho(hIcmp, address.S_un.S_addr, pOutData, wDataSize,
            NULL, pReply, dwBufferSize, dwTimeout) )
    {
        error(GetLastError(), NULL);
    }

    else
    {
        rv = ( pReply->Status == IP_SUCCESS  ) ?
                pReply->RoundTripTime :
                ( ( pReply->Status == IP_REQ_TIMED_OUT ) ? -1 : -2);
    }

    IcmpCloseHandle(hIcmp);
    FreeMem(pOutData);
    return rv;
}

</icmpapi.h></ipexport.h>