由应用程序决定底层数据包是否通过的问题

我把网卡收到的数据传到应用层后由应用层决定该包是否抛弃(驱动通过共享内存、共享事件来通知应用；应用通过CTL_CODE通知驱动），但是发现分片包（比如ping xxx -l 60000）的时候还没有等我的CTL_CODE传递到驱动就已经Time out了，想问问驱动和应用通过CTL_CODE通讯是否比较耗时间，能有什么其它好办法吗？

我试图修改packet中OOBS数据的ReceivedTime但是发现还有此问题，请问高手问题可能出在哪里？有什么好办法解决？

可以考虑将过滤规则下到驱动中，不必将数据传上来。

如果是TCP数据，应用层可以发RESET包，进行阻断

我想在应用层作应用协议（http、smtp、pop3、oicq、icq、telnet、dns等）的过滤，如果都在下面写那很耗时间，关键就是要做阻断功能，而且还要有简易的防火墙功能。

可以考虑用socket进行过滤处理吧。因为你要过滤的都是应用层的。

SPI能够实现你所说的功能，看看费尔1.0的代码吧

噢，ICMP协议除外

我还想抓取Mac，Spi可以吗？

[编辑 -  6/30/04 by  chili]

这个问题搞了很久了，还是换种思路算了。。。。哎
再加个队列，底层建立一个线程监视..。。.

SPI抓不到mac，spi是工作在socket之下
用winpcap吧，不过要处理WAN的话，要分析比较多的数据包

处理速度上不必担心，100M环境肯定没有问题。关键是处理方法要合理。SPI上做防火墙有缺陷。
Microsoft提供了一种firewall hook，也是在驱动。我猜测本意是提供FIREWARE的功能。现在也不建议采用了（见DDK），而是建议IMD做类似的工作。

我开辟了个共享队列由应用和驱动来共同维护此队列
1.开辟个共享队列由驱动和应用共同维护
2.收发包时把数据包保存在队列中不发送但告诉protocol/nic收发成功，同时通知上层有数据包到来要处理。
3.应用收到数据包通知后读取、分析数据然后决定该报是否阻断（通过对共享数据中的某个节点的某个Flag做标记）.....
4.在驱动中也建立线程监控共享队列中的数据是否在应用中做了标记（有效、已读、已处理等）然后来决定是否发送
5.我测试过ping 65500的数据包的时候系统处理不会造成丢包
.这样可以由应用程序来决定某个包能否通过。

我开始发此初帖的时候（想每来一个包然后由上面决定然后通知线面是否通过）没有考虑到网卡收发包的速度比事件通知快，走了很多弯路（第一次搞驱动，高手们多帮助我）。


[编辑 -  7/19/04 by  chili]

方法很好

多谢asmsys以前的指点 :)，小弟没分可送了，唯一的一分留着舍不得送人。

我开辟了个共享队列由应用和驱动来共同维护此队列
1.开辟个共享队列由驱动和应用共同维护
2.收发包时把数据包保存在队列中不发送但告诉protocol/nic收发成功，同时通知上层有数据包到来要处理。
3.应用收到数据包通知后读取、分析数据然后决定该报是否阻断（通过对共享数据中的某个节点的某个Flag做标记）.....
4.在驱动中也建立线程监控共享队列中的数据是否在应用中做了标记（有效、已读、已处理等）然后来决定是否发送
5.我测试过ping 65500的数据包的时候系统处理不会造成丢包
.这样可以由应用程序来决定某个包能否通过。

我开始发此初帖的时候（想每来一个包然后由上面决定然后通知线面是否通过）没有考虑到网卡收发包的速度比事件通知快，走了很多弯路（第一次搞驱动，高手们多帮助我）。


[编辑 -  7/19/04 by  chili]

太好了，我正在考虑这个问题呢。很惭愧，我自己做的这点东西总是做做停停。谢谢chili。

后来我又增加了一个队列.....,数据包交互的方式可以调整

后来我又增加了一个队列.....,数据包交互的方式可以调整

是不是发送的数据包一个队列，接收的数据包一个队列？

你所说的数据包交互方式调整是指什么？

gz

这可能是目前最好的方法了，速度快，不会丢包。其实如果你关心IDS技术的话就会知道，这两年IDS技术里面叫的最响的就是网络驱动和IDS过滤采用共享内存的方法，可以极快的提高分析速度（因为免去了数据包从内核级内存拷贝到用户态内存空间的时间）。不过之前我们做的都是linux下的，比较容易实现。

gz什么意思啊，看着看着，非常高兴，来个不懂的，一头雾水

gz-关注！