Forum Replies Created
-
Posts
-
Тема с 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 [email protected] 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.
WinpkFilter 3.0.2 was released 2007-Apr-30, so this is an old news. The coming release will be 3.0.4.
I have e-mailed to you the InnoSetup script which was used to generate the run-time library available for download from this site. You can use it for the reference. However, setup procedure is fully described in help file. You must be doing something wrong if driver does not get loaded.
If I want to order ndisrd.sys driver source code, pls tell me what contents or components is contained in its source code base?
It contains the complete source code for the NDIS hooking and IM drivers.
For windows x64 OS, why not continue to adopt NDIS-hooking technology, but official IM driver scheme for ndisrd.sys?
Windows XP/2003 x64 introduced PatchGuard technology which protects NDIS.SYS export table from modifications (if PatchGuard finds that NDIS.SYS was modified then it crashes the system). This is also true for Vista/2008 x64. Preventing PatchGuard from doing is job is possible but requires kernel modifications and these modifications are different for different kernel builds because MS updates PatchGuard each time when they got informed there is a way to workaround the current implementation.
I search winpkfilter over google and find that an Austria-based company DeskSoft(http://www.desksoft.com) builds its product BWMeter upon WinpkFilter, is it true? Can u confirms that if u don’t mind?
Yes, it is true.
WinpkFilter installation does not write any license information into the registry and basically installation steps you have performed are correct. Have you rebooted the system after adding the registry key?
I just tried to compile PacketSniffer project under VB6 and it worked just fine. The resulted binary also works without any crashes.
In you case do you get VB environment or PacketSniffer application crash?
I see two possibilities:
1) Create a virtual network interface on top of RS232
2) Use VirtNet+WinpkFilter+special application working with WinpkFilter passing data between RS232 and VirtNet adapter.First approach requires driver coding but more solid in design, second one can be implemented completely in user mode.
