NT与2000协议层处理的不同之处在哪里？精通TCP/IP协议者请进！

最近测试驱动才发现一个问题：

1、在NT平台与2000平台之间进行TCP通信的时候，没有使用TCP的数据区，一个ftp连接IP包的长度一般为0X2C；但是2000之间的一个ftp连接IP包的长度一般为0X30，我仔细分析过了，并不是TCP进行数据补齐处理，而是什么数据？我就是不知道这数据是干嘛用的，哪位大虾精通TCP协议，指教一下如何？？？

2、现在2000之间进行ftp（走ESP传输/隧道）通信时，明明ftp的server端已经开始构造了一个三次握手之后的欢迎信息包了，可就是没有从协议层下来到我的驱动层呢？导致ftp的client一直等啊等，等到超时了，我靠！当然走透明方式是肯定没有问题的了，可是我看了透明方式的IP包的长度和我加密方式的解密明文后的IP包的长度都是一样的，其他信息都正常，可是就是不通！

3、这个问题与TCP的超时重发是否有关系？我说的是刚开始的握手包，基本流程如下：
                        长度0X30
a：client―――――――――SYN―――――――――>server
                        长度0X30        
b：server―――――――――ACK―――――――――>client
                        长度0X28
c：client―――――――――SYN―――――――――>server
                        长度0X30
d：server―――――――――ACK―――――――――>client

问题就发生在c：和d：，这时候client应该发送一个包长为0X2E的包，server应该发送一个包长为非0X30的包，可是server端此时还是发送的是b：的重复包。

问题有可能就是c：引发的，帮忙分析一下，有分！！！

你在打印看看发送端的信息，再在接受端看看收到解密后的信息一样不？ESP处理后的IP包校验和算对没的?

我把打印信息贴出来，大家一块研究一下，我在这里指的都是加密之前和解密之后的明文包。

1、握手包的第一个包：

客户端发送的包：
45 00 00 30 00 8F 40 00 80 06 00 00 C0 A8 02 07 C0 A8 02 09 04 1A 00 15 B5 D7 5E 98 00 00 00 00 70 02 40 00 A5 1F 00 00 02 04 05 B4 01 01 04 02
服务端接收的包：
45 00 00 30 00 8F 00 00 80 06 B4 D8 C0 A8 02 07 C0 A8 02 09 04 1A 00 15 B5 D7 5E 98 00 00 00 00 70 02 40 00 A5 1F 00 00 02 04 05 B4 01 01 04 02

2、握手包的第二个包：

服务端发送的包：
45 00 00 30 03 52 40 00 80 06 72 15 C0 A8 02 09 C0 A8 02 07 00 15 04 1A C6 06 80 0C B5 D7 5E 99 70 12 44 70 5A 8B 00 00 02 04 05 B4 01 01 04 02
客户端接收的包：
45 00 00 30 03 52 00 00 80 06 B2 15 C0 A8 02 09 C0 A8 02 07 00 15 04 1A C6 06 80 0C B5 D7 5E 99 70 12 44 70 5A 8B 00 00 02 04 05 B4 01 01 04 02

3、握手包的第三个包：

客户端发送的包：
45 00 00 28 00 90 40 00 80 06 00 00 C0 A8 02 07 C0 A8 02 09 04 1A 00 15 B5 D7 5E 99 C6 06 80 0D 50 10 44 70 85 7B 00 00
服务端接收的包：
45 00 00 28 00 90 00 00 80 06 B4 DF C0 A8 02 07 C0 A8 02 09 04 1A 00 15 B5 D7 5E 99 C6 06 80 0D 50 10 44 70 85 7B 00 00

4、开始出错了，服务端开始发重复包了：

服务端发送的包：
45 00 00 30 03 53 40 00 80 06 72 14 C0 A8 02 09 C0 A8 02 07 00 15 04 1A C6 06 80 0C B5 D7 5E 99 70 12 44 70 5A 8B 00 00 02 04 05 B4 01 01 04 02
客户端接收的包：
45 00 00 30 03 53 00 00 80 06 B2 14 C0 A8 02 09 C0 A8 02 07 00 15 04 1A C6 06 80 0C B5 D7 5E 99 70 12 44 70 5A 8B 00 00 02 04 05 B4 01 01 04 02

我看不出第三个包有什么问题，可是服务端接收到之后应该没有通过TCP的考核，可能被丢弃了，所以开始了重复包的交互。但是具体不知道如何没有通过？还有我用工具可以看到服务端的上层应用已经开始构造欢迎之类的信息包了，但是就是没有发到协议层或者是驱动层。各位讨论一下吧；）

大家都是菜鸟吗？竟然没有人回答呢；）

昨天又发现新的情况，就是握手后的第一个欢迎信息包从server端发送出来之后，到了client之后接收的IP包发生了改变，我说的是透明处理流程，就是TCP选项和数据后面的那些数据区在传输之前和接收之后大不相同了，可是竟然能通，哈哈，这是为什么呢？

我用sniffer捕获的IP包和client接收的是一样的，可能是我打出的信息地址太靠前了吧？我是NDIS刚刚调用我的MPSend函数不久的地方开始捕获的，就是NdisQueryPacket和NdisQueryBuffer之后的地方打印输出包信息内容的，但是与对方接收到的包信息内容后面部分大不相同，所以我准备在NdisSend之前打印输出包信息再看看；）

有哪一位对中间层驱动的多协议绑定比较了解？给分！！！

问题已经基本搞清楚了，原来是2000系统的ipsec和安全策略在捣乱，我靠，让我大费周折，还以为我的驱动有什么问题呢。为了大家不再走弯路，本人打算进行源代码拍卖，起价1万，一个月有效！！！

注释：我的驱动包含ipsec协议，各种加密算法，策略，与上层应用通信的源代码，别怪我要价太高，实在是血汗与出卖身体健康换来的；）

安装驱动用snetcfg -l inf文件全路径 -c s -i ms_passthru，但是有可能需要指示给系统驱动所在的路径？！即使和inf文件放在相同的路径下也会弹出驱动文件所在路径，不知道是为什么？