Forum Replies Created
-
Posts
-
IP fragmentation does not cares about upper protocols, so only first fragment of the fragmented TCP packet has a TCP header. You should buffer fragments by IP ID, not by TCP sequence number and so on…
I would advise to look through some good book devoted TCP/IP protocols before trying to implement something like this. You definitely need better understanding of the networking basics. I would recommend Richard Stevens books (TCP/IP Illustrated), but ofc this is not the only option.
I gather the answer is “no”. WinpkFilter is just a way to enable me to easily add such code. True??
Yes, thats right.
Well, WinpkFilter was designed mainly for packet filtering solutions but not for spoofing. Interface functions for sending packets are designed as non-blocking for better performance and sending packets through the WinpkFilter at the rate above the network bandwidth causes packet loss (this caused by network limits, not the WinpkFilter internal queue size). Basically you can change your application to send packets on some fixed realistic rate to avoid packet loss. This can be implemented with a waitable periodic timer, which callback routine would calculate time passed since last fireup and how many data should be passed during this time at the given rate. Then send calculated amount of data on the network and requeue the timer. Such approach will allow you to send packets on the network at a given rate which should be chosen below the real network bandwidth.
payload Correct for TCP packet, for UDP an example it would be
payload and so on…
Is this ethernet checksum (http://folk.uio.no/od/tcp-ip-intro/subsection3_2_3.html) something which I need to care about (in addition to the length / checksum fields in the other headers)? Or is this computed automatically?
It is hardware checksum and you won’t even see it on NDIS level.
Unfortunately it is not so easy, as there may be many ethernet packets for each TCP/IP packet.
Well, yes, IP packet can be fragmented and you may have to gather all fragments before processing the packet. However, fragmented IP packets are rather rare in modern networks, also these packets are recommended to be blocked by firewalls. Basically, I don’t think you will ever meet fragmented TCP packet, but it is still possible to generate fragmented ICMP or UDP packets.
Can I implement this with WinpkFilter? Is there a better way?
Am I missing something in the walkthrough provided above?
How do I buffer multiple ethernet packets and (after processing) send them to their intended destination using WinpkFilter? I know how it works for one packet at a time, but what about multiple?In general the approach is correct. Sending multiply packets does not differ from sending a single one.
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 не наблюдалось, видимо у Вас где-то ошибка или стоит какой-то очень специфический софт с подобным же драйвером, сложно сказать что-то конкретное. Если конечно это повторяется на абсолютно чистых системах, значит что-то действительно сделано неправильно…
