Forum Replies Created
-
Posts
-
I assume you mean VLAN tagging (inserting 4 additional bytes into the ethernet header). Well, current version of WinpkFilter limits the size of Ethernet frame to 1514 bytes but there is no problem to extend it to 1518 (or even to 1522) bytes if network card supports such a frame size (does it?).
However, does Windows TCP/IP stack supports VLAN? I just suspect that even if VLAN used the tags are stripped before packet reaches the TCP/IP stack…
First of all I don’t think that there is any documented way to access ICS table.
However, if you filter on the internal interface(LAN) you can differentiate packets destined to the external network (Internet) from the packets destined to the ICS server by their destination IP address. It is hardly possible possible on the external interface (after NAT applied), however you still can use information gathered (build your own copy of NAT table) on the internal network card.
Windows XP firewall can be configured to do drop/pass the packets you want. On the other hand WinpkFilter driver processes packets before TCP/IP stack and built-in firewall so basically you can make routing yourself.
Нет готового нет, шаблон для 9x TDI фильтра есть например в VToolsD, так что в принципе сделать аналог можно. Шаблон для LSP есть в MSDN. Так что в принципе задача не слишком сложно решается.
Для поддержки 98 нужно делать отдельный драйвер (там совсем по другому выстроен сетевой стек), или использовать LSP.
Можно ли получить (купить) такую модификацию драйвера (LHMON я так понимаю), которая сообщает только про создание/удаление соединений и не логирует сами пакеты (это будет делать WinpkFilter)?
Можно при условии приобретения Developer или Source Code лицензии.
Идея вроде ясна. Но, данное сопоставление оказывается ненадежным вовсе не из-за портов (типа, надо просто локальные сравнивать), а из-за того, что пакет от “LocalHost” приходит позже, чем пакет от “WinpkFilter”. Т.е. возможно заблокировать только последующие пакеты, с опозданием, упустив их некоторое количество. Вроде и ничего, но возможна путаница, когда неблокируемое приложение займет локальный порт сразу за тем, как там пыталось работать то приложение, пакеты которого должны дропаться.
Да правильно, я рекомендовал использовать TDI-фильтр (аналогичный LHMON) или LSP для сбора информации процесс<->адрес.порт. Но перехватывать именно пакет данных для построения таблицы соотвествий не нужно. До того момента как любой пакет достигнет NDIS а затем и TDI для него уже существуют ассоциированные структуры представляющие собой соединение (сокет) по которым можно сопоставить пакет процессу(с оговоркой если для пакета существует ассоциированный процесс). LHMON как сниффер не логирует (для user-mode клиента) создаваемые/уничтожаемые соединения но сами эти события отслеживает, чем меньше событий логируется тем меньше нагрузка на процессор (чтение каждой записи лога это переключение контекста). Кстати для одного заказчика делалась модификация драйвера который так же логировал возникновение соединений, для подобных фаервольных целей насколько я понимаю…
I assume you have expirienced problem with the recently generated custom build. The update was sent to you, there was a registry configuration problem skipped by standard custom build tests. I’m really sorry that it has happened
with your build.If you meet any problems with the custom build please contact support@ntkernel.com directly, so we can faster check the issue. Thanks for your patience.
There are no know compatibility problems with XP built-in firewall.
the firewall “eats” all the processing power
Which process takes the most of processor time?
Hmm, this is pretty strange, probably the driver start setting you have used have a problem in this case. As I had mentioned before driver should start after NDIS.SYS and before TCPIP.SYS in order to intercept TCP/IP protocols registration and binding adapter’s process. This is the only required condition. Regretfully I can’t say more without putting hands on these systems…
Probably all these systems have some common software which prevents WinpkFilter from working normally. Without using the kernel debugger it’s usually not easy to detect the conflicting software. What kind of VPN software do you use? It can be also based on NDIS hooking drivers and conflict with WinpkFilter.
WInpkFilter is fully compatible with Windows built-in firewall and ICS.
1. I should to change these values (Group: “Streams Drivers” Start: 1) in the registry?
Current WinpkFilter build installed with the settings above.
3. If I later unistall Kerio, these values will not break work of the driver?
No, there is no actual dependency from the Kerio driver.
Driver can’t to detect network cards RTL8139/810X Family Sad
(Windows XP SP2) – any comments?There are no problems with any network cards because the details of realization or each one are hidden inside NDIS. The problem you have expirienced rather specific to the software installed (firewalls, traffic counting monitoring tools and etc.). Also it may appear that the driver start load order is broken…
Can you give more info about it?
How I must install driver?
What version of Kerio has conflict with WinPKFilter?Actually the only requirement for WinpkFilter driver is starting between NDIS.SYS and TCPIP.SYS, but some hooking drivers(like the case with Kerio) may add additional conditions (like start before or after these drivers). In case with Kerio the conflict was detected when WinpkFilter driver strats before Kerio driver, but the problem gone if WinpkFilter starts after Kerio. Thats why we had changed load order to “Streams Drivers” Start:1. However, the situation may change from release to release (by the date of the post mentioned the problem was with the newest Kerio release, and there were no problems with previous releases).
