TDI client（使用rawIP重新路由报文）

使用IMD做VPN隧道封装后，由于IP目的地址的改变，必须更换MAC地址，为了方便，我们选择直接调用TDI接口重新路由报文。方法参考DS中的driverNetWork中的例子。调试成功，本来想高呼万岁，却发现一个致命的错误：如果使用了AH认证算法，由于重新发送的IP头是系统重构的，导致AH认证的失效。
   这主要是怪我偷懒，由于相关的例子里都是使用L\"\\\\Device\\\\RawIp\\\\#protocol\",我们也就创建了多个设备，分别支持ESP和AH等协议，因为没有找到直接包含IP报文头的RAWIP发送方法，就沿用ICMP的方式发送了，ESP没有问题，AH就惨了，隧道肯定不通。
   在应用层RAWIP的API的接口中可以通过setsockopt()设置HDRINCL来自己组织IP头，但是在TDI中我却没有找到相关资料（DDK就不说了，他没有提供任何TCPIP的TDI相关资料，我只有阅读DriverNetWork的代码来搜寻），不知道那位有相关的资料或者解决思路。
   我还有一个疑问，使用了类似HDRINCL方案，系统是不是肯定不动IP头，只是加一个MAC头呢？
  说实话，我真的有点恐惧，也许TDI接口编程，并不是简单修改一个标志就可以将IP头也包括进去。也许我使用最直接的方法，自己在IMD中实现路由和ARP的。
  


[编辑 -  7/18/03 by  longfoot]

写了两天，就你说的那个ARP，路由表解决了。

但偶更加郁闷，现在对死结点的处理，麻烦更多了
现在总是内存包耗光，还是没找的原因。唉，痛苦

写了两天，就你说的那个ARP，路由表解决了。
//自己做？不会吧，不到最后关头，我可不想找麻烦
但偶更加郁闷，现在对死结点的处理，麻烦更多了
//死结点是怎么回师亚
现在总是内存包耗光，还是没找的原因。唉，痛苦

偶不是做IPSEC
是做NAT,那个路由表,其实也不是一个真正的路由表.
所谓死结点,就是指,你发一个包出去,但是没有回复.
一个包没有回应,它所占的资源就不会释放,
//现在主要的问题还不是这个.

偶不是做IPSEC
是做NAT,那个路由表,其实也不是一个真正的路由表.
所谓死结点,就是指,你发一个包出去,但是没有回复.
一个包没有回应,它所占的资源就不会释放,
//现在主要的问题还不是这个.

起时间线程扫描吧．

有很多问题要解决，单单起时间是不够的。
这相当于是个优化的问题，以后来处理