Forum Replies Created
-
Posts
-
Если не секрет, как решалась ситуация когда длинна 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.
Vista is relatively new stuff and I can’t advise much about it. However I would try to set a debug privilege for the GUI process instead of editing ACL.
Hmm, in the meantime firewall driver interface is not open for public. However I understand your requirements and if you are a licensed user then please send an e-mail to support(at)ntkernel.com. I don’t see any objections to open firewall interface to licensed users. Please note that firewall API is a C++ DLL which is a wrapper around driver I/O control codes. You should be able to use it from managed C++ (if make C style wrappers then from any environment which support calling functions from C DLL).
Some filtering techniques overview can be found here http://www.ntkernel.com/w&p.php?id=14
You can use drivers IOCTL interface in kernel mode, though it would be far easier to modify the original driver to add the functionality you need.
Well, first of all WinpkFilter x86 standard build (NDIS hook based) you probably downloaded from this site ignores IPv6 protocol (you still can see incoming IPv6 packets as they are also delivered to IPv4) and works with IPv4 only. Though it can be easily extended to support IPv6, but it require rebuilding driver binary. Such sort of modification is available to licensed users.
x64 standard build also available from this site is based on NDIS IM driver and by default it works with both IPv6 and IPv4.
WinpkFilter has an internal packet pool for 500 packets. This size was chosen according real networking requirements and can be changed. If this pool is too large it is just waisting of memory, if it is too small it may decrease real network performance. In your test cases these 500 packets were not enough for such high sending rate and many packets were just dropped by WinpkFilter.
TCP is very different from UDP, it won’t send more packets than fit in maximum window size before receiving receipt confirmation. So such situation like you got with UDP is not possible.
1514 bytes is a network media limit for 802.3 Ethernet (actually it is 1518 bytes but two extra bytes exist only on the physical media and not visible by software). 14 bytes are used for Ethernet header, so maximum IP MTU is 1500 bytes. All IP packets above this size are fragmented by TCP/IP stack. In your case 7900 bytes UDP packet will be fragmented to 6 IP packets and only first fragment will contain UDP header. You can reconstruct the packet from fragments received from WinpkFilter driver if you need to do so.
Some modern network cards (Gigabit Ethernet) may support frames larger than 1514 bytes (9000 bytes “jumbo frames”). WinpkFilter driver can be extended to work with these larger frames (default on site build does not support them and limits MTU to normal 1514 bytes), but I don’t think this is your case, correct me if I’m wrong.
