Hi All!
I am developing a virtual miniport driver that basically has an NDIS upper edge, and a WDM lower edge (based on the netvmini sample). During normal operation everything works fine; packets are sent and received correctly. However, when I load up ethereal or windump (using winpcap) and start capturing, it appears that ethereal and windump see all the packets, but the apps don’t. For example, I can ping a remote computer just fine when ethereal isn’t running, but when it is capturing, ethereal sees the ping requests and replies, but the actual ping program just keeps timing out. Any idea what can cause this? I am using ethereal 0.99 and winpcap 3.1. I figure that somehow NDIS isn’t sending a copy of the received packets to all the bound protocols. Is there any way to check and debug this?
Regards,
Jess Howe
Viasat
Jess,
The problem seems to be due to the HW filter set with
OID_GEN_CURRENT_PACKET_FILTER. Whenever a protocol sets it to
NDIS_PACKET_TYPE_PROMISCUOUS or NDIS_PACKET_TYPE_ALL_LOCAL, for some strange
reason that I don’t know, NDIS seems to deliver the packets to one protocol
only (what usually happens is that the TCP/IP protocol driver doesn’t
receive them).
I’ve seen this with the WinPcap protocol driver, as well with the sample
protocol driver from the DDK (ndisprot), when it’s bound to some virtual
miniports.
It would be really interesting to know what’s causing this, and if there is
a (un)documented workaround.
Gianluca Varenni
WinPcap Team
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Friday, September 29, 2006 4:29 AM
Subject: [ntdev] NDIS issue?
> Hi All!
>
> I am developing a virtual miniport driver that basically has an NDIS upper
> edge, and a WDM lower edge (based on the netvmini sample). During normal
> operation everything works fine; packets are sent and received correctly.
> However, when I load up ethereal or windump (using winpcap) and start
> capturing, it appears that ethereal and windump see all the packets, but
> the apps don’t. For example, I can ping a remote computer just fine when
> ethereal isn’t running, but when it is capturing, ethereal sees the ping
> requests and replies, but the actual ping program just keeps timing out.
> Any idea what can cause this? I am using ethereal 0.99 and winpcap 3.1. I
> figure that somehow NDIS isn’t sending a copy of the received packets to
> all the bound protocols. Is there any way to check and debug this?
>
> Regards,
> Jess Howe
> Viasat
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
hello,
i am developing the NDIS miniport driver. i am getting the Tx packets, i.e. send pakets but not able to receive packets. can any body help me who have already implement it.
please tell me how to create a packet and send it to upper layer. i dont have a NIC card but physical layer is different. i have created a packet but some exceptions occurs and it is crashing.
look into it and help me.
thanks
hitesh
Hitesh,
I just use the code included in the netvmini sample source code included in the windows DDK. It has all the code you need to indicate a packet up. Also, check out ndis.com and this link: http://ndis.com/pcakb/KB01060101.htm.
Regards,
Jess Howe
Gianluca,
The problem still happens even when I uncheck capture in promiscuous mode in wireshark (I got it working). I notice the the filter is always being set to 0xb, which is DIRECTED, MULTICAST, and BROADCAST. I don’t know if that information helps at all, but I thought I’d clarify that it still doesn’t work right even when it’s not in promiscuous mode.
Regards,
Jess
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 03, 2006 5:33 AM
Subject: RE:[ntdev] NDIS issue?
> Gianluca,
> The problem still happens even when I uncheck capture in promiscuous mode
> in wireshark (I got it working). I notice the the filter is always being
> set to 0xb, which is DIRECTED, MULTICAST, and BROADCAST. I don’t know if
> that information helps at all, but I thought I’d clarify that it still
> doesn’t work right even when it’s not in promiscuous mode.
> Regards,
> Jess
>
I know that. When you uncheck promiscuous into wireshark, the filter is set
by WinPcap to NDIS_PACKET_TYPE_ALL_LOCAL (0x80). It’s interesting to see
that the miniport sees a 0xb filter, instead.
I hoped to see an explanation to this behavior from some Ndis guru or some
Microsoft folk…
Have a nice day
GV
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>It’s interesting to see that the miniport sees a 0xb filter, instead.
NDIS_PACKET_TYPE_ALL_LOCAL is not *really* a filter specification for the
Miniport - the Miniport behaves no differently than with
DIRECTED+MULTICAST+BROADCAST and NDIS will indicate that combination to the
MP. NDIS_PACKET_TYPE_ALL_LOCAL is a flag to NDIS itself to loop-back all
other binding’s packet sends into this binding so that it observes all
traffic across the interface, sent and received. I suppose this is to allow
a packet monitor to observe all of the traffic without effecting the packet
filter with such a heavy hand as to set it into promisuous mode (although
with switched network infrastructure, promiscuous mode is hardly the
performance issue It might have been on COAX ethernet. All you x-DEC-ies
remember drilling pressure taps?).
Good Luck,
Dave Cattley
Consulting Engineer
Systems Software Development
----- Original Message -----
From: “David R. Cattley”
To: “Windows System Software Devs Interest List”
Sent: Tuesday, October 03, 2006 9:25 AM
Subject: RE: RE:[ntdev] NDIS issue?
>
>>It’s interesting to see that the miniport sees a 0xb filter, instead.
>
> NDIS_PACKET_TYPE_ALL_LOCAL is not really a filter specification for the
> Miniport - the Miniport behaves no differently than with
> DIRECTED+MULTICAST+BROADCAST and NDIS will indicate that combination to
> the
> MP. NDIS_PACKET_TYPE_ALL_LOCAL is a flag to NDIS itself to loop-back all
> other binding’s packet sends into this binding so that it observes all
> traffic across the interface, sent and received. I suppose this is to
> allow
> a packet monitor to observe all of the traffic without effecting the
> packet
> filter with such a heavy hand as to set it into promisuous mode (although
> with switched network infrastructure, promiscuous mode is hardly the
> performance issue It might have been on COAX ethernet. All you x-DEC-ies
> remember drilling pressure taps?).
It would be interesting to know then why sometimes NDIS behaves in a weird
way when the ALL_LOCAL or PROMISCUOUS filters are used…
Anyone from the MS NDIS team here??
Have a nice day
GV
>
> Good Luck,
> Dave Cattley
> Consulting Engineer
> Systems Software Development
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
hello,
i am developing miniport driver. i am able to get the packets (from protocol driver to down side ) but dont know how to send packets to upper layer. can anyone tell me what are the things to be taken care while creating and sending the packets to upper layer( protocol driver).
i have data frame with 14 bytes of header. shall i send the frame with header or without header?
if it is without header then how come the protocol driver come to know about the source mac address?
also tell me about the other settings which needs to be taken care.
my sequence is like this,
Allocate buffer (data frame is with header)
chain buffer at front,
and indicate receive,
are these steps are sufficient or i need to take care about the others also like set mac header or set some length anywhere??
thanks
from
hitesh
On Oct 5, 2006, at 1:49 AM, xxxxx@yahoo.co.in wrote:
hello,
i am developing miniport driver. i am able to get the packets (from
protocol driver to down side ) but dont know how to send packets to
upper layer. can anyone tell me what are the things to be taken
care while creating and sending the packets to upper layer
( protocol driver).
This is pretty basic stuff and is well covered in the DDK and
samples. You should look at the netvmini sample in the current DDK;
it has a very straightforward example of how to indicate packets up
to the OS.
The exact details of how you indicate packets up to the OS depend on
your NIC - handling the interrupt, transferring data, etc. - but
eventually you will probably wind up in NdisMIndicateReceivePacket().
You really need to spend some time reading in the DDK. Look in the
NDIS design guide for miniports.
-sd
> i have data frame with 14 bytes of header. shall i send the frame with header
or
without header?
The first buffer of NDIS_PACKET must contain at least the lookahead size
required by the protocol above.
NDIS_SET_PACKET_HEADER_SIZE must be called with 14 bytes (Ethernet header).
if it is without header then how come the protocol driver come to know about
the
source mac address?
It is always with MAC header.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com