相当诡异的情况,不知各位大虾遇到过没有?

时间:2021-09-20 20:53:21
最近用VC仿真TCP,求校验和的时候,出现了一个相当诡异的情况,让我一筹莫展,请教各位了。
我直接执行的时候,输出结果显示总是会有固定的几个包有问题,算校验和不正确,于是我就逐步调试,奇怪的现象发生了,之前的错误全都不复存在,我再直接执行,问题又来了。反复几次都是这样。我就郁闷了,这有错也找不出来了啊。
我想因为校验和是所有首部及数据部分相加,这种情况是不是跟溢出有关?
各位达人帮帮我吧,纠结很久了,感激不尽啊!

16 个解决方案

#1


代码?

#2


楼主贴点代码吧

#3


在中间插入一些输出语句试试

#4


把代码贴出来看看

#5


unsigned int checksum(PKT_PTR pkt)
{
    int j=0;
    unsigned int r_buf1=0,r_buf2=0,r_buf=0;
    while(pkt->data[j]!='\0'){pkt->pseh->length++;j++;}
  
    for(j=0;j<pkt->pseh->length;j++)//计算数据部分的校验和
{
 if(j%2==0){r_buf1=pkt->data[j]<<8;r_buf+=r_buf1;}
 else {r_buf2=pkt->data[j];r_buf+=r_buf2;}
 }
    pkt->pseh->length=pkt->pseh->length+20;//计算TCP总长度,即数据长度+20字节首部,在此未考虑选项字段
     pkt->tcp->length=5;
    pkt->tcp->ack_numh=pkt->tcp->ack_num>>16;
    pkt->tcp->ack_numl=pkt->tcp->ack_num&65535;
    pkt->tcp->seq_numh=pkt->tcp->seq_num>>16;
    pkt->tcp->seq_numl=pkt->tcp->seq_num&65535;
            
    pkt->tcp->checksum = pkt->pseh->sourceiph+pkt->pseh->sourceipl+pkt->pseh-> destiph+pkt->pseh->destipl+pkt->pseh->pro_value+pkt->pseh->length
+pkt->tcp->source_port+pkt->tcp->dest_port+pkt->tcp->ack_numh+pkt->tcp->ack_numl+pkt->tcp->seq_numh+pkt->tcp->seq_numl+(pkt->tcp->length<<12)+pkt->tcp->mix+pkt->tcp->window+pkt->tcp->urgent+r_buf;
     
      pkt->tcp->checksum= 65535-(pkt->tcp->checksum&65535);//计算校验和
       printf("The check sum is %d\n",pkt->tcp->checksum);
      return pkt->tcp->checksum;
}

这个就是计算校验和那部分的程序,可能看着有点费劲,变量太多了,那个诡异的结果我倒是截了图,可惜不晓得怎么粘上来……
所有的变量都是unsigned int型的

#6


printf("The check sum is %d\n",pkt->tcp->checksum); 
这句话输出的结果,逐步调试和直接执行还不一样

#7


也就是说每次运行都不一样?
还是仅仅调试和直接运行结果不同?

pkt->tcp->checksum还真有可能溢出

#8


是调试和直接运行结果不同

那溢出了要怎么解决呢?我换成过long型的,没有什么区别,请教了

#9


根据我的一些调试经验,如果调试模式和直接执行的行为有区别,通常是某些数据在调试环境中和直接执行时的值不同导致的。而这种不同产生的原因通常是未初始化的变量等。你可以按照这个思路检查一下。

#10


试试别的求校验和方法,如用异或.

#11


再换大点变量属性呢

#12


我之前遇到过的一个问题。也许对你有帮助。可以参考一下,为你解决bug提供一点思路。

http://topic.csdn.net/u/20090714/08/f4298cb3-a60e-4def-9493-b4a76cb23996.html

#13


给点分吧

#14


MARK

#15


TCP是基于流不是基于包传输的。
意思就是如果调用
send(aaaa);
send(bbbb);
send(cccc);
可能
aa=recv()
aab=recv()
bbbccc=recv()
c=recv()

#16


我的QQ:183282952
加我。
我对你的问题很感兴趣。
想帮你看看。

加我详谈。

#1


代码?

#2


楼主贴点代码吧

#3


在中间插入一些输出语句试试

#4


把代码贴出来看看

#5


unsigned int checksum(PKT_PTR pkt)
{
    int j=0;
    unsigned int r_buf1=0,r_buf2=0,r_buf=0;
    while(pkt->data[j]!='\0'){pkt->pseh->length++;j++;}
  
    for(j=0;j<pkt->pseh->length;j++)//计算数据部分的校验和
{
 if(j%2==0){r_buf1=pkt->data[j]<<8;r_buf+=r_buf1;}
 else {r_buf2=pkt->data[j];r_buf+=r_buf2;}
 }
    pkt->pseh->length=pkt->pseh->length+20;//计算TCP总长度,即数据长度+20字节首部,在此未考虑选项字段
     pkt->tcp->length=5;
    pkt->tcp->ack_numh=pkt->tcp->ack_num>>16;
    pkt->tcp->ack_numl=pkt->tcp->ack_num&65535;
    pkt->tcp->seq_numh=pkt->tcp->seq_num>>16;
    pkt->tcp->seq_numl=pkt->tcp->seq_num&65535;
            
    pkt->tcp->checksum = pkt->pseh->sourceiph+pkt->pseh->sourceipl+pkt->pseh-> destiph+pkt->pseh->destipl+pkt->pseh->pro_value+pkt->pseh->length
+pkt->tcp->source_port+pkt->tcp->dest_port+pkt->tcp->ack_numh+pkt->tcp->ack_numl+pkt->tcp->seq_numh+pkt->tcp->seq_numl+(pkt->tcp->length<<12)+pkt->tcp->mix+pkt->tcp->window+pkt->tcp->urgent+r_buf;
     
      pkt->tcp->checksum= 65535-(pkt->tcp->checksum&65535);//计算校验和
       printf("The check sum is %d\n",pkt->tcp->checksum);
      return pkt->tcp->checksum;
}

这个就是计算校验和那部分的程序,可能看着有点费劲,变量太多了,那个诡异的结果我倒是截了图,可惜不晓得怎么粘上来……
所有的变量都是unsigned int型的

#6


printf("The check sum is %d\n",pkt->tcp->checksum); 
这句话输出的结果,逐步调试和直接执行还不一样

#7


也就是说每次运行都不一样?
还是仅仅调试和直接运行结果不同?

pkt->tcp->checksum还真有可能溢出

#8


是调试和直接运行结果不同

那溢出了要怎么解决呢?我换成过long型的,没有什么区别,请教了

#9


根据我的一些调试经验,如果调试模式和直接执行的行为有区别,通常是某些数据在调试环境中和直接执行时的值不同导致的。而这种不同产生的原因通常是未初始化的变量等。你可以按照这个思路检查一下。

#10


试试别的求校验和方法,如用异或.

#11


再换大点变量属性呢

#12


我之前遇到过的一个问题。也许对你有帮助。可以参考一下,为你解决bug提供一点思路。

http://topic.csdn.net/u/20090714/08/f4298cb3-a60e-4def-9493-b4a76cb23996.html

#13


给点分吧

#14


MARK

#15


TCP是基于流不是基于包传输的。
意思就是如果调用
send(aaaa);
send(bbbb);
send(cccc);
可能
aa=recv()
aab=recv()
bbbccc=recv()
c=recv()

#16


我的QQ:183282952
加我。
我对你的问题很感兴趣。
想帮你看看。

加我详谈。