Forum Replies Created
-
Posts
-
Drivers are not displayed in Task Manager which shows only user mode processes. You can see services associated with the virtual NIC’s (like in case with VMware), but not the drivers themselves.
Sending modified packet does not differ from sending unmodified one, however take care to recalculate packet checksums.
Судя пр крашу пакет переданный в NdisMSendComplete уже не валиден. Какой статус был возвращен из MiniportSend? Используется ли MiniportSendPackets?
Вряд ли кто-то сможет что-либо по этому отписать, поскольку неясно даже где и с каким кодом падает. Хотя бы выход с !analyze-v запостил…
Тема с TCPSendData раскрыта тут http://www.ntkernel.com/w&p.php?id=17
Эту функцию нужно перехватывать дополнительно.
In common the order of network adapters reported by WinpkFilter is not permanent. Network adapters are added into the list in the order of their initialization by the system, in most cases it is always the same for the particular system, but it is not guaranteed to be.
It is better to identify network interfaces by their internal names instead of the index in the network adapters list.
UPDATE 1: It appears the problem is related to the Firewall with Hamachi. Is there a way to totally exclude filtering on a specific interface? I configured all to rules to be binded to the real interface and the Hamachi virtual nic is set to “Low Level Security” but I think we should have another option for “Disable Filtering on this Interface” (or kind of). Thanks!
The conflict between low level network software is quite possible. By default NeT Firewall intercepts all network adapters bound to TCP/IP and this can’t be change through the management console. It would require rebuilding NeT Firewall driver with a special check on Hamachi network interface.
I will check what really happens with Hamachi once I have some spare time.
WinpkFilter 3.0.4 released. This service release includes:
1) Compatibility fixes in WinpkFilter API DLL and drivers
2) x64 driver support for 32 bit code running in WOW64. This feature should be useful for developers whose development tools does not include x64 native compiler. An example, Delphi 32-bit application can work with WinpkFilter driver on Windows x64.
3) Kernel level filters. You can load a filter table into WinpkFilter driver which defines rules for packet pass, block or redirect_and_ process by your application. This may seriously improve perfomance.
4) C# interface and samplesImportant note:
For Windows Vista and later versions of the Windows family of operating systems, kernel-mode software must have a digital signature to load on x64-based computer systems. WinpkFilter drivers are not signed and in order to test them on Vista x64 you should press F8 during system boot and choose Disable Driver Signature Enforcement option. For the commercial software you’d have to obtain Code Signing certificate from Verysign or another Certificate Authority authorized by Microsoft.If you are eligible for a free update, please send the following details to support@ntkernel.com to receive an update instruction:
1. Your order ID.
2. An approximate date of purchasing.If I use this code and trace it using packet sniffer it sends the packets. I am sending the packet to local PC itself. But in the sniffed packet I see Frame check sequence error. Will it create any problem. Can u please tell me why the error occurring ? And what I am missing here ?
The code above initializes only Ethernet header and sets next protocol as IP without initializing the IP header. This may cause sniffers to show this packet as a bogus one.
Packets [received from]/[sent to] WiFi network interface are normal Ethernet 802.3 frames (WiFi NIC driver strips 802.11 specific headers). So basically at the NDIS level WiFi network interface does not differ from normal LAN interface and packets can be processed at the same way.
1- can winpkfilter supporte WIFI paquets ?.
Yes
2- Is the paquets captured by winpkfilter ara the original paquets or
just a copy of original? .Not sure what you really mean here, but if you modify the packet which is sent/received over WiFi it will come modified to network/MSTCP. This is unlike winpcap which gives you a copy of the packet and its modification won’t change anything.
I suppose the problem is not in the engine but in what you do with packets:
if(pPktDes->ePktDirection == VG_PACKET_FROM_NIC)
{
memcpy(pEthHdr->h_dest, dstMac, ETH_ALEN);
memcpy(pEthHdr->h_source, srcMac, ETH_ALEN);
if(!VgPdeTransmit((char *)pPktDes->pPktBuf,pPktDes->nPktLen,VG_PACKET_TO_NIC))
{
PdeDemoShow("IpHandler@VgPdeTransmit errorn");
return FALSE;
}
}
else /* from MSTCP */
{
if(!VgPdeTransmit((char *)pPktDes->pPktBuf,pPktDes->nPktLen,VG_PACKET_TO_NIC))
{
PdeDemoShow("IpHandler@VgPdeTransmit errorn");
return FALSE;
}
}I don’t know what are the MAC addresses you have used are taken from. But if the address you set as source MAC does not match the NIC address you send the packet from then you may meet problems. In Windows all packets sent on the network are normally indicated back to protocol (so called hardware loopback). It is posssible to use NDIS_FLAGS_DONT_LOOPBACK or/and NDIS_FLAGS_SKIP_LOOPBACK flags (set for the packet in INTERMEDIATE_BUFFER.m_Flags) to prevent the loopback but these packets are system specific and not guarantee to work properly on every Windows, though I used them just fine for the Ethernet Bridge. WinpkFilter normally filters out the loopback packet by checking the source MAC address (packet is skipped if source MAC = NIC MAC), but in your case it may fail to do so (if source MAC does not match the NIC address) and even single packet starts going in the endless loop (from application to WinkFilter, then From WinpkFilter to NIC, from NIC to WinpkFilter, from WinpkFilter to application and so on) -> 100% CPU load.
You can read this topic on forum regarding the loopback packets:
Not sure why you may need this, but you can swap source and destination Ethernet and IP addresses (you may also need to do something with TCP?UDP headers if necessary). Then just use SendPacketToMstcp instead SendPacketToAdapter.
