|
20楼#
发布于：2002-12-05 12:10
No problem!
估计损失多少文？我被别人偷了皮夹子那次，损失了三千多文，更惨痛的是身份证、卡一起飞掉了，惨淡！！！！！！！！！ 痛定思痛，每次坐车我都是往人少的地方去，谁碰我一下， 马上回头看一眼什么人物。 总之，以后小心 好了，哥们，阳光还是灿烂的吗：（） |
|
|
|
21楼#
发布于：2002-12-05 12:27
用那个快速的方法的时候，如果packet里面没有老的校验和怎么办？
|
|
|
|
22楼#
发布于：2002-12-05 12:29
指针设NULL， 长度设0，
OK了 |
|
|
|
23楼#
发布于：2002-12-05 12:35
有的时候在passthru里面取到的校验和是错误的，不是在协议层算出来的
|
|
|
|
24楼#
发布于：2002-12-05 12:55
checksum的计算范围是有规定的，不同修改要计算不同的值，
|
|
|
|
25楼#
发布于：2002-12-05 13:04
ip头的校验和
|
|
|
|
26楼#
发布于：2002-12-05 13:11
ip头的校验和 不仅是IP头， 对于TCP和UDP，修改必须包括TCP/UDP头中校验的更新 |
|
|
|
27楼#
发布于：2002-12-05 13:22
我的意思是说如果你取到的ip头的旧的校验和是错的怎么办？？
|
|
|
|
28楼#
发布于：2002-12-05 13:32
已经被别人修改过的东西，并且修改错了，应该会被协议层踢掉，
所以，只有全部从新计算。 这种会发生吗？什么情况下发生？暂时没有见过 |
|
|
|
29楼#
发布于：2002-12-05 13:39
不是被别人修改错了，而是协议层压根就没有算，那只是一个随机的数，但不是空的，留给底层去算的，这种情况会有，但不会经常发生
|
|
|
|
30楼#
发布于：2002-12-08 12:22
RFC中的Chcksum的偶数算法还要加上一个限制条件：
被修改的数据之前的数据字节数也必须是偶数位,否则计算的结果是错的 |
|
|
|
31楼#
发布于：2002-12-08 13:30
但是 NAT 支持 FTP 时，处理后包可能变长（经常就是变一个字节），这么说就只能用全校验了？！
|
|
|
32楼#
发布于：2002-12-09 09:12
肯定是他妈的大头鬼写错了
|
|
|
|
33楼#
发布于：2002-12-09 09:28
算法的通用性在于他的普遍实用性，只要校验算法是一致的，就应该适用。
|
|
|
|
34楼#
发布于：2002-12-09 14:42
仔细看过这个inf以后发现，有个东西很好笑，Service的ID是好像不对，我看DDK中（我说的是那本驱动程序开发大全）是跟inf中不一样的，不过，我查了MSDN,那个值又是跟inf中的一样的了，不知道哪个是正确的？？
|
|
|
35楼#
发布于：2002-12-09 15:55
INF 里面是正确的，文档总得服从实践检验吧 :)
|
|
|
36楼#
发布于：2002-12-10 10:56
奇数位的校验方法快实现了，实现了会帖出来共享
edust 我发给你的MAIL收到了吗？我是从帖子下面的发信中发去的。 |
|
|
|
37楼#
发布于：2002-12-10 11:00
啊？我已经回复了啊，你没收到吗？
|
|
|
38楼#
发布于：2002-12-10 11:09
邮箱里空空，
可能是服务器有问题，麻烦再给我发一份吧，换个邮箱 MAIL： fuq_dddd@263.net |
|
|
|
39楼#
发布于：2002-12-10 11:32
又发了一次（用刚才你说的这个地址），请查收。
|
|