SendIP bug report about ipv6.c

[YangGeH3C]

1、现象：
当模拟发送ipv6版本，且差分服务代码点等于63时，即通信分类介于248-251时的报文时，如：
sendip -p ipv6 -6s 200::11 -6d 188::11 -6t 248 -p tcp -ts 159 -td 160 -d 0x0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF01234567 188::11
报文内容不符合预期。正常情况下，DSCP应该为0xF8。

2、原因：
ipv6.c中70行，算法获取报文长度只有前4位（0x0F000000转化为2进制为1111000000000000000000000000），短于通信分类的长度8比特。
case 't':
/* TODO : This looks byte-order dependant */
hdr->ip6_flow |= htonl(((u_int32_t)strtoul(arg, (char **)NULL, 0) << 20) & 0x0F000000);
pack->modified |= IPV6_MOD_FLOW;
break;
如果计算差分服务代码点等于63时，需要通过与逻辑运算，获取至少5个及以上的报文长度。
如果计算整个通信分类，代码应将&逻辑操作的对象更改为0x0FF00000。

3、修改建议：
修改0x0F0000000x0FF00000，这样可以获取完整8比特长度的通信分类：
hdr->ip6_flow |= htonl(((u_int32_t)strtoul(arg, (char **)NULL, 0) << 20) & 0x0FF00000);

1. Situation:
   Prepare to send the packet simulated by
   (1) The version is IPV6.
   (2) And the DSCP(Differential Service Code Point) equals 63 which means the traffic class is between 248-251.
   For example:
   sendip -p ipv6 -6s 200::11 -6d 188::11 -6t 248 -p tcp -ts 159 -td 160 -d 0x0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF01234567 188::11
   But the packet is not as expected. The DSCP should be 0xF8 as follows:

2. Cause:
   The code on line 70 in Ipv6.c, the length of the packet obtained by the algorithm is only the first 4 bits (0x0F000000 converted to binary is 1111 0000 0000 0000 0000 0000 0000), which is shorter than the length of the traffic class by 8 bits.
   case 't':
   /* TODO : This looks byte-order dependant */
   hdr->ip6_flow |= htonl(((u_int32_t)strtoul(arg, (char **)NULL, 0) << 20) & 0x0F000000);
   pack->modified |= IPV6_MOD_FLOW;
   break;
   The code supposed to calculate a 5-bits packet(0x0F800000 converted to binary is 1111 1000 0000 0000 0000 0000 0000) at least through logical operation while simulating the DSCP equals 63.
   The code should change the object of logical operation to 0x0FF00000 for whole traffic class.

3. Suggestions for modification:
   Modify 0x0F000000_0x0FF00000 to calculate whole 8-bit length traffic class:
   hdr->ip6_flow |= htonl(((u_int32_t)strtoul(arg, (char **)NULL, 0) << 20) & 0x0FF00000);

[ptpt52]

my change for this:
ptpt52/sendip@47cd3a9

[ptpt52]

fixed in ptpt52/sendip@01832e4

[rickettm]

Please open a PR and I'll merge, thanks

[ptpt52]

@rickettm
very strange, why there is multi version of sendip
it looks like my copy of version is great diff from yours
https://github.com/ptpt52/sendip/commits/master

not easy to creat PR

[rickettm]

Ugh. So it looks like you created yours by downloading a tarball of ... something ... checking it in to git and then making changes. The reults is a bit of a mess.
Where did you get the tarball from in the first place?

[ptpt52]

@rickettm
hi, likely I download it from here https://www-x.antd.nist.gov/ipv6/sendip/