A road named NoNameUno

Few inferences ( without looking at online doc or any reference materials ) --

1) miniport register its interrupt handlers with ndis.

2) Ndis itself process interrupt at DPC level. And it dispatches interrupt to the corresponding miniport(s). So miniport does not have DIRQL. How ndis dispatches to miniports is not known yet to me. But the discussion can wait!

3) Having ms scheduler in the path makes fair bit of code processing in the tcpip. So will try to knock off scheduler later, and inject another filter instead to see what processing steps are in the new setup.

4) ???

Next stop to traverse the data payload in this scenario...

I would like to trap the data payload at the WSK level (the  higher the level the better it is ). On route comes ntkrpamp, when I set bp on echosrv!WskSampleOpReceive. I don't know what is ntkrpamp, but after couple trail I get the data payload in PWSKSAMPLE_SOCKET_OP_CONTEXT->DataBuffer. Note that the socket has different state, so I made sure where to bp to track the connected state's path. Also since the requestor ( usr level client) is not under kernel debugger, you will see timeout of the client side connection and you will fail to capture the data payload... Rembember, I'm using the "Sight, Sound, and smell of Random Debugging"... 

So I know at the highest level that my payload data "hello" is coming from the client. Next I will try to tear out the NDIS_BUFFER_LIST. After that I will go back to the receive path again to fill in the blanks of the  "Mechanics of NDIS processing at a conceptual level".

Note that I'm after the structure and organization of this ndis processing stack  ... So few questions I would llike to ask myself and find answers to them are ---

1) What is a minimal structure I need to have to create WSK client to WSK povider, ane why so ?

2) What is the ndis6.0 filtering mechanism, and what is, yet 'gain, the minimal structure to legoed with NDIS wrapper.

 3) Same questions for a miniport ...