Forum Replies Created
-
Posts
-
Looks like a dead lock on the driver level (conflict with another NDIS-hook driver). What kind of VPN are using? Is it built in Windows VPN or third party one? Do you use any third party firewalls on that system?
is it possible that the fregments are the reason of this problem?
how should i manage the fregment packets? manage the WinpkFilter driver the fregments?The packet you introduced just is not IP packet at all. It can be ARP/RARP, IPX or anything else. Don’t forget to check protocol field in Ethernet header before parsing an arbitrary packet. And no, this can’t be an IP packet fragment, each of the fragments has a correct IP header.
Is the IM driver liable to break in Vista whenever MS patches the OS?
As far as I know IM drivers were not declared depreciated in Vista, so probably they won’t be unexpectedly dropped in one of the forthcoming SPs.
Will Vista support be upgraded to use the native Windows Filtering Platform or do you have a timetable when that might be rolled in?
WPF is relatively new and I would refrain from using it until Vista finally released along with final new WDK. The only WPF sample from beta WDK I seen so far was not able to send requests (NdisRequest) to the underlying NDIS miniports. May be it will be fixed (or even already fixed) but in the meantime it is a serious limitation.
I’m sorry but there are no public WinpkFilter builds with Vista x86 support available for download. The normal x86 package you could get from this site supports only Windows 9x/ME/NT/2000/XP/2003.
Windows Vista (both x86 and x64) are supported by NDIS IM build of WinpkFilter. In the meantime WinpkFilter NDIS IM used only for Windows XP/2003 x64, but it can be also compiled for x86 and used on Windows Vista x86. As soon as Vista is released for public we will add new WinpkFilter installation packages for public download (in the meantime it is available only to registered customers on special request for testing purposes).
WinPkFilter IM Driver seems to work with Vista
Yes, it does. Just need to fix the conversion of internal adapter name to user friendly one, but it can wait till Vista release.
I have signed the driver image, but Windows still complains about an unsigned driver. Do I have to package inf and sys files to a .cat file? Perhaps anybody has a short hint for me?
Have not tried myself yet, but as far as I understand you have two options, one is creating .cat file and another is embedding signature into the driver image. This papaer from MS covers some of the details:
http://www.microsoft.com/whdc/winlogo/drvsign/kmcs_walkthrough.mspx
Probably you can use raw winsock interface. Basically WinpiFilter allows you to query local MAC address, for getting MAC address for remote system you’d have to generate an ARP request packet and then process ARP reply one.
MSTCP is the name of TCP/IP protocol on Windows 9x/ME, but in context of WinpkFilter it is used to specify Microsoft TCP/IP module on Windows systems.
Sending packets to MSTCP means that packet will be indicated to TCP/IP stack from the name of the specified network interface (just like this packet would arrive to this network interfcae from the real network). By other words packet is injected into the upstream between network card and TCP/IP stack.
Sending packets to adapter means that packet will be sent directly to network interface from the name of TCP/IP protocol. By other words packet is injected into the downstream between TCP/IP and network card.
when i start to log all packets with NetFirewall it only showes TCP and UDP connections.
does it means that the firewall only manage this two protocols?NeT Firewall works just below TCP/IP and processes all IP protocols (IP, ICMP, IGMP, TCP, UDP and etc…). Probably you had not any other protocols activity when the log was collected.
when i setup my adapter to “High Security Level”.
does the programm blockes all other protocols which are not listed in the Security Rule table to allow this one ??“High Security Level” blocks every packet unless there is an allow rule matching this particular packet
what happen with IP, IGMP, RAW….. packets?
If there are no allow rules configured to pass these protocols then these packets are blocked on “High Security Level”.
В смысле С.С++ обьявления идентичны, единтсвенное по разному массивы приходится адресовать. А вот в случае C# интерпретация похоже отличается. Ну тут надо смотреть отладчиком что да как…
Сложно сказать (не являюсь поклонником С#), но предположить можно. Драйверу то все равно что за кусок памяти ему передали, он с ней работает как со структурой языка C и соответтвенно заполняет данными. Так что тут дело в том как C# интерпретирует полученную бинарную структуру, а он похоже то же самое обьявление интерпретирует по другому (возможно где-то неявно доставляются элементы, которых обычный С/C++ не добавляет). Думаю не ошибусь если предположу что в C# еть какое-то обьявление которое может заставить компилятор интерпретировать структуру как структуру С, а не managed C#. Что-нибудь подобное extern “C”, ведь как-то стандартные Win32 структуры обрабатываются нормально, думаю стоит посмотреть хидеры.
I have started to use SerpentFly’s suggestions, thus:
PEPROCESS pEprocess = PsGetCurrentProcess();
HANDLE SectionHandle = pEprocess->SectionHandle;I guess you are going to create a driver which supports all NT operating systems, so first of all you have to determine operating system version and then depending of it use the matching EPROCESS definition (from one post above). An example for Windows 2000 it would be as the following:
PEPROCESS_W2K pEprocess = (PEPROCESS_W2K)PsGetCurrentProcess();
HANDLE SectionHandle = pEprocess->SectionHandle;How can I create the new Ethernet packet?
Allocate buffer to store the packet, initialize Ethernet and IP (ICMP, UDP, TCP headers), copy packet data.
On the other hand, would it be possible to send this ethernet packet to a certain port inside the same machine with this application?
Yes, this is possible.
Hmm, since you are going to create CoClient protocol driver and call manager I assume you have CoNDIS WAN driver for your device. If yes then probably you already have a separate call manager or this CoNDIS WAN driver is an MCM driver. Please clarify.
