如何修改ip地址和tcp/udp的port？TDI?NDIS？

需要截获IP包，修改ip地址和tcp/udp的port。然后传递给上层。

应使用TDI filter还是NDIS Intermediate driver?
因为对TDI filter了解不多，NDIS IM driver肯定是可以的。

同时需要支持PPP adapter，而passthru据PCAUSA称是不支持ppp的。

想问的是：
1。可否用TDI filter来完成这个功能。
2。如果TDI filter不行，如何改造NDIS IM，像PCAUSA的NDIS hooking那样。

谢谢！
另外想给分多点，但是系统说可用给分范围是0－20，所以只好给20了。
请各位大侠指教。

TDI Filter就可以搞定了，而且还有一个好处就是Loopback的数据也能拦截得到。

TDI Filter就可以搞定了，而且还有一个好处就是Loopback的数据也能拦截得到。

有没有类似passthru这样的sample便于学习TDI filter的呢，
或者别的网上资源、书等？

 多了PCAUSA有一个基于TDI的Passthru，是个很好的参考。

我这里有一个，给你瞧瞧吧。

想再清楚一点，TDI filter是不是工作在TCP/IP协议栈之上的？

一个接收到的包，被TDI filter修改了ip地址和port后，应用程序
看到的是修改后的地址还是原来的？

这会不会影响到Tcp的tcb内容？

好多的例子哦。

我这里有一个，给你瞧瞧吧。

哪里？
这里有精华区吗？

好多的例子哦。

谢谢，谢谢。

插一句，

有几点我不是很明白，
1. 每个网络数据包是否都有自己的校验码？
2. 在修改IP、Port或数据包长度的同时，还需要修改那些数据包中的数据域？

希望得到指点

1. 每个网络数据包是否都有自己的校验码？

是的，但这个是在链路层，TDI这一层不管的。

2. 在修改IP、Port或数据包长度的同时，还需要修改那些数据包中的数据域？

如果你只是修改IP和Port或者长度，不需要你修改其他的域。

如果要处理 ICMP 包，那要考虑的情况和要修改的地方就多了！

 

如果要处理 ICMP 包，那要考虑的情况和要修改的地方就多了！

现在我没有时间详细看有关rfc文档，哪位明白人指点一下，
icmp需要额外考虑那些因素？


 

如果你只是修改IP和Port或者长度，不需要你修改其他的域

fracker，你的意思是说，数据包头的部分是不没有校验的，
而对于实体――包头后的数据是有校验的，那么采用的是哪种校验方法，在包头里面有描述码吗？

[quote]1. 每个网络数据包是否都有自己的校验码？

是的，但这个是在链路层，TDI这一层不管的。

2. 在修改IP、Port或数据包长度的同时，还需要修改那些数据包中的数据域？

如果你只是修改IP和Port或者长度，不需要你修改其他的域。 [/quote]
1。我想他是指ip头的checksum和tcp/udp的checksum，这些都要修改的，不过可以参考rfc－nat的算法。

 

1。我想他是指ip头的checksum和tcp/udp的checksum，这些都要修改的，不过可以参考rfc－nat的算法。

那么，在Miniport、IMD、Protocal、tdi中的哪一层驱动上做改动时，
需要重新计算checksum？

另外，rfc－nat的文档到哪里可以找到，是否有相应的原码？

谢谢！！！！！！！！！

[quote] 1。我想他是指ip头的checksum和tcp/udp的checksum，这些都要修改的，不过可以参考rfc－nat的算法。

那么，在Miniport、IMD、Protocal、tdi中的哪一层驱动上做改动时，
需要重新计算checksum？

另外，rfc－nat的文档到哪里可以找到，是否有相应的原码？

谢谢！！！！！！！！！ [/quote]
rfc-3022
ftp://ftp.rfc-editor.org/in-notes/rfc3022.txt
源码可以参考linux netfilter nat部分的代码。算法蛮简单的。

我是驱动新手，所以也不清楚应该在哪层上改，不过直觉来说，既然改动包内容了，就一定要改checksum。无论在哪一层都应该这样。

我也是新手，大家同进。

不过，我认为checksum只是为了对数据进行校验，确保通信的安全稳定，
我个人感觉，协议层以上就没有意义了，但不是很确定？

我的理解，好像每个驱动层都有自己的checksum，
Miniport层应该是包含mac的checksum，依次类推，
Protocal层是包含协议头的checksum，这样每通过一层驱动，
去掉一个checksum，最后协议层以上就没有必要了，
如果是这样，tdi又起到什么作用哪？

看样子对网络通信的细节还不是很了解，希望高人为两个小鸟指点。

谢谢！！！！！！！！！！！

rfc-3022
ftp://ftp.rfc-editor.org/in-notes/rfc3022.txt
源码可以参考linux netfilter nat部分的代码。算法蛮简单的。

我是驱动新手，所以也不清楚应该在哪层上改，不过直觉来说，既然改动包内容了，就一定要改checksum。无论在哪一层都应该这样。
 

知觉不表示正确。
如果采用拦截Winsock API方式修改IP和Port，你上哪里去修改Checksum？

重新贴一遍，

fracker

不过，我认为checksum只是为了对数据进行校验，确保通信的安全稳定，
我个人感觉，协议层以上就没有意义了，但不是很确定？

我的理解，好像每个驱动层都有自己的checksum，
Miniport层应该是包含mac的checksum，依次类推，
Protocal层是包含协议头的checksum，这样每通过一层驱动，
去掉一个checksum，最后协议层以上就没有必要了，
如果是这样，tdi又起到什么作用哪？

看样子对网络通信的细节还不是很了解，希望高人为两个小鸟指点。

谢谢！！！！！！！！！！！

在Miniport层没有校验，MAC层带4字节的CRC，但一般由网卡MAC控制器完成，IP层的IP包头带有ChkSum校验，若修改了IP地址必须修改该校验，否则该包会被丢掉。UDP层对整个UDP包都有ChkSum校验，修改UDP包头中的端口必然也要改该校验。但该校验可以设为0，即为忽略。另外UDP包最大可以为65535字节，但以太网中IP包最大为1500字节，此时若UDP包大小超过1480字节则该UDP包将被拆分为多个IP包，其中只有第一个包还有UDP包头，可以改端口，后面的包只有通过IP包头里的ID来识别。这就是在Miniport层或Protocol层修改需要注意的事项，TDI Filter层我没做过，但我想它应该收到的是完整的UDP包，不需要考虑这一点。