I’ve extended the NAT sample code and introduced packet forwarding between interfaces, so that packets on the client interface are read on RECEIVE, run through the NAT, and then changed to SEND on the internet provider interface, with similar path for returning data.
At some point, somewhere around 10 minutes after I start packet capturing (8-12 minutes, typically) the call to “while(m_NdisApi.ReadPacket(&Request))” starts taking a few hundred milliseconds. I’ve put timestamped log prints immediately before and after the read call. When everything is functioning correctly, the ReadPacket call takes under 1 ms, which is all the more acurate I’m logging. After this roughly 10 minute point, ReadPacket takes 150-300 ms to complete, leaving the network of my host computer the NAT computer unusable.
It also appears that the point at which I issue a SetEvent to signal the NAT thread to stop, ReadPacket returns to taking less than 1ms. It then reads 400 packets (I’ll assume this is just whatever is left in the queue) within the next 100ms before exiting.
I’m convinced that something I am doing is causing this, as I have several test apps that do either just my NAT code, or just the packet forwarding, and they don’t exhibit this behavior. Has anyone seen something like this? Have suggestions on places to look at?