Ping issue in 1.20+

[Denys Vlasenko]

On Thursday 27 June 2013 23:49, Denys Vlasenko wrote:
> On Thursday 27 June 2013 20:13, Giovanni Vallesi - TeeBX wrote:
> > Hi All,
> > after updating from busybox 1.19.4 to 1.20.2 or 1.21.0 I got a strange 
> > issue using the ping applet:
> > - The first icmp packet is sent and get the target reply as expected.
> > - The applet continue sending icmp, but no console output.
> > - Interrupting the applet report ping statistics with a large number of 
> > missing packets.
> > 
> > After some network debugging I discovered that the every icmp packet 
> > sent after the first one has a wrong checksum. Below the first two 
> > captured packets in hex format.
> > 
> > 161	45.089741	172.31.255.109	172.31.255.1	ICMP request
> > (correct checksum 0x5D76)
> > 0000   00 a0 f9 2a 28 d0 00 0c 29 9b 9e 39 08 00 45 00  ...*(...)..9..E.
> > 0010   00 54 00 00 40 00 40 01 e3 fa ac 1f ff 6d ac 1f  .T.. at .@......m..
> > 0020   ff 01 08 00 5d 76 3e 06 00 00 46 7a 16 09 00 00  ....]v>...Fz....
> > 0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > 0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > 0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > 0060   00 00                                            ..
> > 
> > 170	46.090539	172.31.255.109	172.31.255.1	ICMP request
> > (wrong checksum 0xAAB9, expected 0x0830)
> > 0000   00 a0 f9 2a 28 d0 00 0c 29 9b 9e 39 08 00 45 00  ...*(...)..9..E.
> > 0010   00 54 00 00 40 00 40 01 e3 fa ac 1f ff 6d ac 1f  .T.. at .@......m..
> > 0020   ff 01 08 00 aa b9 3e 06 00 01 8c bf 25 09 00 00  ......>.....%...
> > 0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > 0040   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > 0050   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> > 0060   00 00                                            ..
> 
> Please add debugging prints to inet_cksum() function - for one,
> let's find out the value of nleft, addr[0], and the return value.
> (IOW, let's find out whether we checksum over the correct buffer,
> and whether we produce the same xsum we see in tcpdump.)

For example, this way:


uint16_t FAST_FUNC inet_cksum(uint16_t *addr, int nleft)
{
        /*
         * Our algorithm is simple, using a 32 bit accumulator,
         * we add sequential 16 bit words to it, and at the end, fold
         * back all the carry bits from the top 16 bits into the lower
         * 16 bits.
         */
        unsigned sum = 0;
char string[nleft*2 + 2];
int z = nleft;
bin2hex(string, (void*)addr, nleft)[0] = 0;
        while (nleft > 1) {
                sum += *addr++;
                nleft -= 2;
        }

        /* Mop up an odd byte, if necessary */
        if (nleft == 1) {
                if (BB_LITTLE_ENDIAN)
                        sum += *(uint8_t*)addr;
                else
                        sum += *(uint8_t*)addr << 8;
        }

        /* Add back carry outs from top 16 bits to low 16 bits */
        sum = (sum >> 16) + (sum & 0xffff);     /* add hi 16 to low 16 */
        sum += (sum >> 16);                     /* add carry */

bb_error_msg("inet_cksum(%s,%d)=0x%x", string, z, (unsigned)(uint16_t)~sum);
        return (uint16_t)~sum;
}

When I run it, I see:

# ./busybox ping -c2 10.0.0.138
PING 10.0.0.138 (10.0.0.138): 56 data bytes
ping: inet_cksum(080000001f29000038717f2500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000,64)=0x4021
64 bytes from 10.0.0.138: seq=0 ttl=254 time=3.116 ms
ping: inet_cksum(080000001f29000117b48e2500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000,64)=0xfc32
64 bytes from 10.0.0.138: seq=1 ttl=254 time=2.747 ms



BTW, I verified with tcpdump that generated checksums
on my machine are correct:
tcpdump -v starts complaining only if I deliberately invert
one bit via "return (uint16_t)~sum ^ 1".

-- 
vda