visual studio - NDIS and miniport driver -

i trying modify ethernet driver using wdk tools provided in visual studio 2012.

the samples provided in wdk 'miniport adapter' , 'ndis light weight filter' among others. still @ beginning of driver writing , hence finding tough navigate through code.

i able install miniport adapter after building in visual studio 2012 [shows 'microsoft virtual miniport adapter' in network adapters list.] able assign ip address , subnet mask also.[i found out not connect physical device on pc].

i setup 'debug view' software check driver messages adapter.[ used 'dbgprint' statements in code , built it.] but, debug messages printed repeatedly.

1- why messages printed again , again? messages 'datapath.c' file of program , function 'mpsendnetbufferlists'. ['net buffer' specifies data sent or received on network.]

2- setup wireshark capture data on adapter , shows there requests arp,http,ssdp,mdns etc coming out of it. not able understand talking adapter? , how can stop talking?

i can use 'ping' see if there connection on ip address have assigned adapter , responds success telling packets sent , there no packet loss.

my goal send , receive 'data' packets via ip address ethernet adapter. ie- want application connect ip address assigned adapter , talk it.

3- can samples provided in wdk?

any other suggestions or advice welcome.

ps- wasn't able use windows debugger built visual studio 2012. used 2 pcs , able connect , install driver onto 'target' pc couldn't breakpoints etc. code , program did nothing after installing driver on 'target' pc. suggestions on this?. thought step-by-step debugging of drivers also.[i know wrong].

thanks aditya

ndis miniport drivers, many low-level drivers, meant talk hardware. miniport's responsibility take send packets os, translate them whatever format required hardware, , instruct hardware send packet on wire.

the wdk (and in fact, used to) include real-world sample driver sends packets on real-world hardware. leads confusion, since real-world drivers have deal lots of hardware-specific details distract main point of sample. if starting real-world driver, first thing you'd have identify hardware-specific bits , rip out, replace them own hardware-specific bits.

instead, "netvmini" sample in wdk fake driver. means pretends have actual hardware, secretly it's lie. when os sends packets netvmini, netvmini driver broadcast packets other netvmini miniport adapters installed on machine. (in effect, installing 2 netvmini adapters on same machine simulates happen if had 2 real adapters plugged same ethernet hub.) in ascii-art, happens if install 2 netvmini adapters on same system:

       tcpip                       tcpip                      tcpip          |                           |                          | real physical miniport        netvmini #1           netvmini #2          |                           \                          /    [the internet]                     [the netvmini virtual hub] 

as ascii-art illustrates, netvmini adapters don't have path internet. driver won't "real" ip address can route internet until add in details of hardware. until then, windows keep trying send arps , http requests never go anywhere.

to answer specific questions:

1. the messages mpsendnetbufferlists printed every time os attempts send packet. because os thinks have real network connection, os make several attempts use it. should quiet down bit, when comes conclusion isn't useful link.

2. the requests coming tcpip. if don't want tcpip send data, unbind adapter.

3. you can send data adapter. in fact, you've observed you're sending random http packets , etc. data won't reach internet, until teach driver how talk real hardware.

if you're sitting there thinking "but don't have hardware!", might want create virtual miniport of sort. virtual miniports netvmini in don't have real hardware, still have way packets off machine. example, vpn miniports operate @ layer-2 (like l2tp) typically install second driver — ndis protocol driver — sends , receives data "real" physical miniport. virtual miniport talks protocol whenever needs packets off machine. result is:

        tcpip           |   virtual miniport           |    ndis protocol           | real physical miniport           |      internet 

there alternative architectures; example, vpn operates @ layer-4 (like sstp) might decide open wsk socket instead of implementing ndis protocol driver:

        tcpip           |   virtual miniport           |       wsk socket           |         tcpip           | real physical miniport           |      internet