Prev: IoCreateDevice returns STATUS_OBJECT_NAME_NOT_FOUND
Next: Confirmation needed, DIFx + Sensor type = No go.
From: Philip Stuyck on 28 Feb 2010 15:24
Reading through the documentation of winpcap kind of confirms my suspicion
It is implemented as a protocol driver not a real miniport.
What I basically need is a virtual adapter which I can configure with its
own ip address and mac address as well, even though in reality there is no
hardware below it. Windows however thinks it is a real NIC driver.
When packets are travelling towards the NIC, I just want to dispatch them to
my own application. Take care of them and handle replies. The replies, for
windows appear as coming from my virtual NIC. So they just travel upwards and
are received by whoever is listening to them.
Conceptually I see nothing wrong with what I want to do:
- Install a virtual adapter driver similar as ms loopback adapter, but not
loopback of course
- the driver dispatches everthing to my own application
- my application is able to send replies to the driver
- the driver handles the replies as if they come from the network (actually
they are coming from the network it is just a virtual one) and the replies
travel up the stack of windows

like this, if my application is running, its own stack configured for
200.200.200.201/24
if I have a virtual adapter on 200.200.200.200/24
in a cmd prompt do ping 200.200.200.201
I would get a reply from my application, for windows it would appear as
coming from a real network.

With the netvmini example and some tweaking of my own, I can see the ARP
message coming in. But this is still a very long way from sending this ARP to
my own application, and form handling replies.

I don't understand that something as easy like this does not exist yet.
Please don't answer vmware, it is just not true.


"Philip Stuyck" wrote:

> I thought that winpcap is only for capturing ethernet frames, not for sending
> own frames in response to what is being received.
>
> "Pavel A." wrote:
>
> > "eagersh" <eagersh20(a)gmail.com> wrote in message
> > news:81d23074-a921-4ae3-b143-bd570c2eeffc(a)e19g2000prn.googlegroups.com...
> > ..........
> > > To the advise of using Winpcap I would like to add that you could
> > > develop your own NDIS Protocol driver and retrieve Ethernet frame
> > > directly from the driver. WDK contains a good example of NDIS Protocol
> > > driver which you could easily modify for your needs.
> >
> > Igor, Winpcap is exactly this: a good example of NDIS protocol driver.
> >
> > regards,
> > --pa
> >
> >
From: Don Burn on 28 Feb 2010 15:37
If I were tackling this I would take the ndiswdm sample as is, then take
the src\geneal\pcidrv\kmdf sample and gut it except for pcidrv.c and
pcidrv.h and use that as a basis for a new driver that sends the
requests upwards to your application using an inverted call mechanism.


Don Burn (MVP, Windows DKD)
Windows Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr




"Philip Stuyck" <PhilipStuyck(a)discussions.microsoft.com> wrote in
message news:331D3E1C-CF13-434E-BAE4-149477D33717(a)microsoft.com:

> Reading through the documentation of winpcap kind of confirms my suspicion
> It is implemented as a protocol driver not a real miniport.
> What I basically need is a virtual adapter which I can configure with its
> own ip address and mac address as well, even though in reality there is no
> hardware below it. Windows however thinks it is a real NIC driver.
> When packets are travelling towards the NIC, I just want to dispatch them to
> my own application. Take care of them and handle replies. The replies, for
> windows appear as coming from my virtual NIC. So they just travel upwards and
> are received by whoever is listening to them.
> Conceptually I see nothing wrong with what I want to do:
> - Install a virtual adapter driver similar as ms loopback adapter, but not
> loopback of course
> - the driver dispatches everthing to my own application
> - my application is able to send replies to the driver
> - the driver handles the replies as if they come from the network (actually
> they are coming from the network it is just a virtual one) and the replies
> travel up the stack of windows
>
> like this, if my application is running, its own stack configured for
> 200.200.200.201/24
> if I have a virtual adapter on 200.200.200.200/24
> in a cmd prompt do ping 200.200.200.201
> I would get a reply from my application, for windows it would appear as
> coming from a real network.
>
> With the netvmini example and some tweaking of my own, I can see the ARP
> message coming in. But this is still a very long way from sending this ARP to
> my own application, and form handling replies.
>
> I don't understand that something as easy like this does not exist yet.
> Please don't answer vmware, it is just not true.
>
>
> "Philip Stuyck" wrote:
>
>
> > I thought that winpcap is only for capturing ethernet frames, not for sending
> > own frames in response to what is being received.
> >
> > "Pavel A." wrote:
> >
>
> > > "eagersh" <eagersh20(a)gmail.com> wrote in message
> > > news:81d23074-a921-4ae3-b143-bd570c2eeffc(a)e19g2000prn.googlegroups.com...
> > > ..........
>
> > > > To the advise of using Winpcap I would like to add that you could
> > > > develop your own NDIS Protocol driver and retrieve Ethernet frame
> > > > directly from the driver. WDK contains a good example of NDIS Protocol
> > > > driver which you could easily modify for your needs.
> > >
>
> > > Igor, Winpcap is exactly this: a good example of NDIS protocol driver.
> > >
> > > regards,
> > > --pa
> > >
> > >


__________ Information from ESET Smart Security, version of virus
signature database 4903 (20100228) __________

The message was checked by ESET Smart Security.

http://www.eset.com


From: Thomas F. Divine on 28 Feb 2010 22:45
If you insure that the Microsoft TCP/IP stack is not bound to your miniport,
then OK.

Thomas F. Divine

"Philip Stuyck" <PhilipStuyck(a)discussions.microsoft.com> wrote in message
news:B0C18D6E-948B-4772-9E36-BE080E1E32D3(a)microsoft.com...
> I am not sure if I understand you.
> I actually started with the example in the DDK NetVmini and activated the
> traces. I changed the code somewhat to see the actual data.
> Then I installed the driver and configured an ip address on this virtual
> adapter : 200.200.200.200/24
> If I then ping 200.200.200.201; the supposed ip address of my application,
> then I see that the driver receive an ARP request message. So if my driver
> would work properly, I would just forward this ARP towards my application
> and
> let him handle it. The application would react with an ARP reply, which is
> sent from application towards the driver I suppose (this is a bit blurry)
> and
> then should go back to the requestor. For Windows it would seem like the
> application is running remote on a network. There is no collision of ip
> stacks that I can see.
>
> "Thomas F. Divine" wrote:
>
>> I would say that WinPcap is a good example of a NDIS protocol driver that
>> is
>> designed specifically to support network monitoring. I would not promote
>> it
>> as the foundation for a non-Microsoft TCP/IP transport.
>>
>> In fact, it is likely that a NDIS protocol driver will not work at all
>> for
>> this idea.
>>
>> Because of the way the Windows network kernel is implemented all NDIS
>> protocol drivers will receive all inbound packets to the host. This
>> presents
>> a problem for a second non-Microsoft TCP/IP implementation. For example,
>> the
>> real Microsoft TCP/IP transport will receive all the packets packets
>> intended for the separate non-Microsoft TCP/IP transport; when it does,
>> it
>> (or some firewall) may send abort or cause other mischief that will cause
>> problems.
>>
>> So, it may be that instead of NDIS protocol driver one may need a NDIS
>> MUX
>> or filter driver. (Or a separate real NIC that is not bound to the
>> Microsoft
>> TCP/IP transport)
>>
>> Thomas F. Divine
>>
>> "Pavel A." <pavel_a(a)12fastmail34.fm> wrote in message
>> news:59EEAD40-A8FB-4F28-994B-9CE71C173EE4(a)microsoft.com...
>> > "eagersh" <eagersh20(a)gmail.com> wrote in message
>> > news:81d23074-a921-4ae3-b143-bd570c2eeffc(a)e19g2000prn.googlegroups.com...
>> > ..........
>> >> To the advise of using Winpcap I would like to add that you could
>> >> develop your own NDIS Protocol driver and retrieve Ethernet frame
>> >> directly from the driver. WDK contains a good example of NDIS Protocol
>> >> driver which you could easily modify for your needs.
>> >
>> > Igor, Winpcap is exactly this: a good example of NDIS protocol driver.
>> >
>> > regards,
>> > --pa
>> >
>> >
From: Maxim S. Shatskih on 1 Mar 2010 12:13
> I actually started with the example in the DDK NetVmini and activated the

Correct.

What you need is the driver which has the miniport upper edge on slave end and the inverted-call-based edge for a dedicated app on master end. In UNIX, such a driver is called "tun", and MS's similar driver used by Virtual PC/Virtual Server is called "tunmp".

Then, the dedicated app sees all packets sent to the virtual adapter driver. It can create one or more virtual MAC addresses within it, and handle the packets according to their destination MACs.

It can also respond to ARP or even DHCP queries.

The other side, which uses the virtual adapter's miniport egde, will see the network world emulated by the app as the real network.

--
Maxim S. Shatskih
Windows DDK MVP
maxim(a)storagecraft.com
http://www.storagecraft.com

First  |  Prev  | 
Pages: 1 2 3
Prev: IoCreateDevice returns STATUS_OBJECT_NAME_NOT_FOUND
Next: Confirmation needed, DIFx + Sensor type = No go.