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: