阅读:3430回复:40
这是 Passthru 的一个 BUG 吗?
今天研究 Passthru 的 INF 文件时发现其中有两句:
Class = NetService ClassGUID = {4D36E974-E325-11CE-BFC1-08002BE10318} 可我查了一下 DDK,NetService 的 GUID 明明是 {4D36E975-E325-11CE-BFC1-08002BE10318} 啊,《Windows 2000驱动程序开发大全》里面跟 DDK 里面写的一样啊,这是怎么回事?不会是故意的吧? |
|
最新喜欢:![]() |
沙发#
发布于:2002-12-10 11:47
已经收到,
谢谢!!!!!!!!!!!!! :D |
|
|
板凳#
发布于:2002-12-10 11:32
又发了一次(用刚才你说的这个地址),请查收。
|
|
地板#
发布于:2002-12-10 11:09
邮箱里空空,
可能是服务器有问题,麻烦再给我发一份吧,换个邮箱 MAIL: fuq_dddd@263.net |
|
|
地下室#
发布于:2002-12-10 11:00
啊?我已经回复了啊,你没收到吗?
|
|
5楼#
发布于:2002-12-10 10:56
奇数位的校验方法快实现了,实现了会帖出来共享
edust 我发给你的MAIL收到了吗?我是从帖子下面的发信中发去的。 |
|
|
6楼#
发布于:2002-12-09 15:55
INF 里面是正确的,文档总得服从实践检验吧 :)
|
|
7楼#
发布于:2002-12-09 14:42
仔细看过这个inf以后发现,有个东西很好笑,Service的ID是好像不对,我看DDK中(我说的是那本驱动程序开发大全)是跟inf中不一样的,不过,我查了MSDN,那个值又是跟inf中的一样的了,不知道哪个是正确的??
|
|
8楼#
发布于:2002-12-09 09:28
算法的通用性在于他的普遍实用性,只要校验算法是一致的,就应该适用。
|
|
|
9楼#
发布于:2002-12-09 09:12
肯定是他妈的大头鬼写错了
|
|
|
10楼#
发布于:2002-12-08 13:30
但是 NAT 支持 FTP 时,处理后包可能变长(经常就是变一个字节),这么说就只能用全校验了?!
|
|
11楼#
发布于:2002-12-08 12:22
RFC中的Chcksum的偶数算法还要加上一个限制条件:
被修改的数据之前的数据字节数也必须是偶数位,否则计算的结果是错的 |
|
|
12楼#
发布于:2002-12-05 13:39
不是被别人修改错了,而是协议层压根就没有算,那只是一个随机的数,但不是空的,留给底层去算的,这种情况会有,但不会经常发生
|
|
|
13楼#
发布于:2002-12-05 13:32
已经被别人修改过的东西,并且修改错了,应该会被协议层踢掉,
所以,只有全部从新计算。 这种会发生吗?什么情况下发生?暂时没有见过 |
|
|
14楼#
发布于:2002-12-05 13:22
我的意思是说如果你取到的ip头的旧的校验和是错的怎么办??
|
|
|
15楼#
发布于:2002-12-05 13:11
ip头的校验和 不仅是IP头, 对于TCP和UDP,修改必须包括TCP/UDP头中校验的更新 |
|
|
16楼#
发布于:2002-12-05 13:04
ip头的校验和
|
|
|
17楼#
发布于:2002-12-05 12:55
checksum的计算范围是有规定的,不同修改要计算不同的值,
|
|
|
18楼#
发布于:2002-12-05 12:35
有的时候在passthru里面取到的校验和是错误的,不是在协议层算出来的
|
|
|
19楼#
发布于:2002-12-05 12:29
指针设NULL, 长度设0,
OK了 |
|
|
上一页
下一页