November 3, 2011 at 6:17 pm #5362
I modify gretunnel to just monitor incoming packet without do anything, but when I send just 5000 UDP packet with 200 byte size, I loose server connection for 2 min! I will be useless for me in such case.
My server is Windows 2008 R2 x64 on HyperV
My code compiled as 32 bit application
My network is 2Mbit internet connection
If I dont run the code I have not such issue, it mean there is not relate to firewall or routers
I am using the latest version of WinpkFilter 188.8.131.52
int main(int argc, char* argv)
void Test(int index, int counter)
ether_header* pEthHeader = NULL;
iphdr* pIpHeader = NULL;
printf ("Driver not installed on this system of failed to load.n");
api.GetTcpipBoundAdaptersInfo ( &AdList );
if ( iIndex + 1 > AdList.m_nAdapterCount )
printf("There is no network interface with such index on this system.n");
Mode.dwFlags = MSTCP_FLAG_SENT_TUNNEL|MSTCP_FLAG_RECV_TUNNEL;
Mode.hAdapterHandle = (HANDLE)AdList.m_nAdapterHandle[iIndex];
// Create notification event
hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
// Set event for helper driver
if ((!hEvent)||(!api.SetPacketEvent((HANDLE)AdList.m_nAdapterHandle[iIndex], hEvent)))
printf ("Failed to create notification event or set it for driver.n");
// Initialize Request
ZeroMemory ( &Request, sizeof(ETH_REQUEST) );
ZeroMemory ( &PacketBuffer, sizeof(INTERMEDIATE_BUFFER) );
Request.EthPacket.Buffer = &PacketBuffer;
Request.hAdapterHandle = (HANDLE)AdList.m_nAdapterHandle[iIndex];
while (counter != 0)
WaitForSingleObject ( hEvent, INFINITE );
bool send = PacketBuffer.m_dwDeviceFlags == PACKET_FLAG_ON_SEND;
//ether_header_ptr ethHeader = (ether_header*)Request.EthPacket.Buffer->m_IBuffer;
// Place packet on the network interface
// Indicate packet to MSTCP
if (counter == 0)
printf ("Filtering completen");
November 4, 2011 at 8:43 pm #7045
Maybe there is something with your packet queue?
Manual says that if you don’t read packets from the queue (with CNdisApi::ReadPacket) or release the queued packets directly by calling CNdisApi::FlushAdapterPacketQueue then after the queue reaches it’s maximum limit all network activities will be frozen.November 8, 2011 at 9:49 pm #7046
Tanks for your reply.
Would you tell me whats wrongs in my code? The code is so simple and it even does not process that packet but it got frozen.
Would you help me?
RegardsNovember 9, 2011 at 1:50 am #7047
I can’t see if your filter application really does anything except console output. However, please note that console output is relatively slow thing and if you call it for every packet this cause a serious delay for each packet processing, thus causing slower reading packets from the queue. May be this was a problem in you case, however, I have not been expecting your code thoroughly. Why you just don’t use the tha passthru sample instead compiled with no console output?November 9, 2011 at 6:45 am #7048
I know console is slow so I just print one counter per 100 packet:
Actually the system network frozen for 1 min or more and when it back i see it even does not process much packet; it doesn’t print much message too.
Actually the code is same ass passthru, as you say i check passthru sample too and I remark all printf output, but still same issue when I send many packet (10000 UDP packets) from client site.
I really going to corporate with you to solve this issue, I can also send you my server admin password to you to check this issue yourself.November 9, 2011 at 10:34 am #7049
WinpkFilter driver by default has 500 buffers for queing packets. When you send a large amount of packets on the network interface which is in the tunnel mode then driver internal queue is overloaded and network will be frozen until your user mode application process all these packets. So the reason is the application which does not process packets fast enough. May be it just does get enough CPU time. Try to assign packet filtering application a higher priority than your UDP sending application has. However, I don’t think that your network is really frozen, you rather expirience a huge packet drops because of massive UDP spoofing and this causes TCP resends and etc…November 9, 2011 at 10:35 am #7050
P.S. You can also try PackThru sample which reads/writes blocks of packets from/to the driver and thus faster processes the queue.November 9, 2011 at 10:41 am #7051
P.P.S. If you plan UDP spoofing on the network interface using large amounts of packets then it also may have sense to create a special WinpkFilter driver build with larger amount of packets buffers.
You must be logged in to reply to this topic.