共2条
1/1 1 跳转至页
ZLG,IP ZLG_IP中校验和计算的小错误

问
if(length&0x01)//长度为奇数个时,要进行该操作
{
sum = sum + ((*check2)&0xff00);
}
这是ZLG_IP中UDP_BACK里的计算校验和程序里的一段代码,长度为奇数的时候执行到这里时check2已经指向最后一个字节的数据,在采用小端结构的计算机里,低字节在前,所以这时候应该是((*check2)&0x00ff);上位机接收到校验和不对的UDP帧就会悄悄丢掉,没有任何警告,所以这样的计算一旦发送奇数长的包就丢包,不知道周公是怎么调试这个程序的?
还有,在Udp.c里的计算校验和是
if(length&0x0001)//长度为奇数个时,要进行该操作
{
sum = sum + ((uint32)check[2*i]<<8);
}
这里利用以太网中和校验不关心字节的顺序来处理奇数帧,是正确的,为什么两个要分别处理? 答 1: 上位机对效验和不对的数据是否丢掉取决于上位机软件,如果软件没有效验CRC,照收不误 答 2: 如果双方协议不用效验CRC协议栈都可以省却这个产生CRC和效验CRC的开销 答 3: CRC是网卡芯片自动加上去的CRC是网卡芯片自动加上去的,自动校验的,不用软件处理,这里的校验是帧内部的和校验,如果发送端没有计算检验和而接收端检测到检验和有差错,那么U D P数据报就要被悄悄地丢弃。不产生任何差错报文(当I P层检测到I P首部检验和有差错时也这样做)。双方是可以协定是否进行校验,Host Requirements RFC声明,U D P检验和选项在默认条件下是打开的。它还声明,
如果发送端已经计算了检验和,那么接收端必须检验接收到的检验和(如接收到检验和不为0)。只是,许多系统没有遵守这一点,只是在出口检验和选项被打开时才验证接收到的检验和。
{
sum = sum + ((*check2)&0xff00);
}
这是ZLG_IP中UDP_BACK里的计算校验和程序里的一段代码,长度为奇数的时候执行到这里时check2已经指向最后一个字节的数据,在采用小端结构的计算机里,低字节在前,所以这时候应该是((*check2)&0x00ff);上位机接收到校验和不对的UDP帧就会悄悄丢掉,没有任何警告,所以这样的计算一旦发送奇数长的包就丢包,不知道周公是怎么调试这个程序的?
还有,在Udp.c里的计算校验和是
if(length&0x0001)//长度为奇数个时,要进行该操作
{
sum = sum + ((uint32)check[2*i]<<8);
}
这里利用以太网中和校验不关心字节的顺序来处理奇数帧,是正确的,为什么两个要分别处理? 答 1: 上位机对效验和不对的数据是否丢掉取决于上位机软件,如果软件没有效验CRC,照收不误 答 2: 如果双方协议不用效验CRC协议栈都可以省却这个产生CRC和效验CRC的开销 答 3: CRC是网卡芯片自动加上去的CRC是网卡芯片自动加上去的,自动校验的,不用软件处理,这里的校验是帧内部的和校验,如果发送端没有计算检验和而接收端检测到检验和有差错,那么U D P数据报就要被悄悄地丢弃。不产生任何差错报文(当I P层检测到I P首部检验和有差错时也这样做)。双方是可以协定是否进行校验,Host Requirements RFC声明,U D P检验和选项在默认条件下是打开的。它还声明,
如果发送端已经计算了检验和,那么接收端必须检验接收到的检验和(如接收到检验和不为0)。只是,许多系统没有遵守这一点,只是在出口检验和选项被打开时才验证接收到的检验和。
共2条
1/1 1 跳转至页
回复
有奖活动 | |
---|---|
“我踩过的那些坑”主题活动——第002期 | |
【EEPW电子工程师创研计划】技术变现通道已开启~ | |
发原创文章 【每月瓜分千元赏金 凭实力攒钱买好礼~】 | |
【EEPW在线】E起听工程师的声音! | |
高校联络员开始招募啦!有惊喜!! | |
【工程师专属福利】每天30秒,积分轻松拿!EEPW宠粉打卡计划启动! | |
送您一块开发板,2025年“我要开发板活动”又开始了! | |
打赏了!打赏了!打赏了! |