Forum Replies Created
-
Posts
-
Basically TDI is above NDIS, but some events logged by TDI filter upon completion, an example in case of sending an outgoing packet TDI filter will pass this packet to NDIS, get the return status and log it after this. So you got packet from NDIS before than from TDI.
Well, the problem is that Cisco VPN client is also utilizes NDIS hooking approach to making network filter driver. As soon as there is no standard for these drivers conflicts are always possible. We will check if we can do anything about it, thanks for reporting.
i take a look at your TDI driver, but it can only monitor ip packets or block packets which match a rule….i want to decide it self…if the packet can pass the TDI-System
is it possible to tunnel packets like your NDIS driver…..
Possible but the driver should be changed for this.
can you help me to find a solution to attach a packet to his process ??
Another option is a Layered Service Provider (LSP), you can read more in MSDN.
@ulli-um wrote:
hi,
what is the reason for the most desktop firewalls to add a combination of NDIS and TDI ?
To get the proccess id which is the packet from??Yes, thats right.
You can find the TDI filtering solution here http://www.ntkernel.com/w&p.php?id=8
Packets can’t bypass NDIS layer, but if you want an application context you need something like TDI filter. Most of the desktop firewalls on the marker is a combination of NDIS and TDI/LSP filters.
Driver code and data are located in non paged memory by default. Though, you can make parts of your driver pageable with a special compiler directives.
Windows XP ICS is not compatible with port forwarding. In the next few weeks a version 3.0 of NeT Firewall will be released. It includes NAT and traffic shaping services, so you can switch to NeT Firewall NAT instead Windows XP ICS.
Если не секрет, как решалась ситуация когда длинна packet + digest > MAX_ETHER_FRAME. Такой пакет отправлялся двумя фрагментами?
Не секрет. Длинна digest была 16 байт, соответственно MTU (протокол запрашивает MTU сетевой карты прежде чем посылать на нее пакеты) уменьшался на эти 16 байт и TCP/IP стек не послылал IP пакеты превышающие 1500-16 = 1484 байта.
В WinpkFilter для этого есть функция SetMTUDecrement, она создает значение в реестре которое драйвер считывает при загрузке (требуется перезагрузка) и уменьшает MTU сетевых адаптеров на указанную величину.
У меня для одного заказного проекта требовалось приписывать хвост пакету из keyed MD5 (HMAC-MD5), на принимающей системе хвост проверялся и отрезался, пакет передавался стеку уже без довеска, то есть насколько я понимаю что-то вроде того что у Вас и требуется.
Никаких проблем с исчезновением приписанного digest не наблюдалось, видимо у Вас где-то ошибка или стоит какой-то очень специфический софт с подобным же драйвером, сложно сказать что-то конкретное. Если конечно это повторяется на абсолютно чистых системах, значит что-то действительно сделано неправильно…
Process context is not available at NDIS (packet level). Alternatively you can build a table for processes<->open ports and use this table to match packet to processes when processing packet at NDIS level. Such a table can be build an example using TDI filter or LSP.
Vista builds are not placed for public download yet, but if you a registered customer and your license has not expired yet then you can request Vista build by sending an e-mail to support(at)ntkernel.com.
I think it makes sense for you to download source doce for the article below:
http://kamburov.net/index.php?/content/view/17/26/
It demonstrates the modification of IP header TTL field in Delphi and can be reference for getting protocol headers.
сразу можно сказать, что неправильные ip_len (т.к. пинг-пакет – 32 байта данных) ip_hl (должен быть равен 20) и ip_p (должен быть равен 1 – протокол ICMP).
ip_len у вас показан как 12288, в 16-ричном представлении это 0х3000, учитывая сетевой порядок байт в пакете получаем 0x0030 = 48 байт. ip_hl измеряется в двойных словах, тут все верно 5 двойных слов (DWORD) это как раз 20 байт. Ну а протокол (ip_p) определен как TCP (6), из картинки не следует что это ICMP пакет, так что осмелюсь предположить что вы ошиблись приняв этот пакет за ICMP.
