Another tool that might be helpful is to do a “netstat -s” – it may
report (via counters) why the packet is discarded at the transport
layer.
Bryan S. Burgin
xxxxx@microsoft.com
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Michal Vodicka
Sent: Tuesday, July 08, 2003 11:52 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Passthru based driver is ignoring the “altered” r
eceived packets - checksums are OK
Good ideas. I have yet another one which used successfully when debugged
IM
driver. Put breakpoint on above driver receive handlers; better is to
set
NDIS_STATUS_RESOURCES as James mentioned to force NDIS use above
ProtocolReceive handler only and no queuing. Indicate your packet and
when a
breakpoint is reached, step through handler and it should be obvious why
is
packet rejected (it examines some piece of packet data and returns).
Some
assembly knowledge is necessary but it is a pre-requisite for driver
developers.
If breakpoint isn’t reached it means packet is broken and refused by
NDIS
itself. In this case NDIS code can be stepped through to see why.
Above driver handlers can be located using ndiskd KD extension or simply
by
symbol list; names are evident. IIRC for tcpip.sys handlers are named
_ArpXxx.
Best regards,
Michal Vodicka
STMicroelectronics Design and Application s.r.o.
[michal.vodicka@st.com, http:://www.st.com]
From:
xxxxx@mindspring.nospam.com[SMTP:xxxxx@mindspring.nospam.com]
Reply To: xxxxx@lists.osr.com
Sent: Tuesday, July 08, 2003 4:43 PM
To: xxxxx@lists.osr.com
Subject: [ntdev] Re: Passthru based driver is ignoring the
“altered”
received packets - checksums are OKThe outline of your logic looks OK. So, …
To begin, I would be running Network Monitor (part of SMS), because
that
will sometimes turn up problems like bad checksums (and might expose
length problems) in things one indicates up.Next, if this not too much trouble, I would try indicating the changed
packet up immediately (rather than queuing it up for later), but still
setting packet status to NDIS_STATUS_RESOURCES, to preserve the
passthru
logic as much as possible. If things still fail, you can exclude the
queuing as part of the problem; conversely, if things succeed, you can
focus on the queuing.Third, I would examine each flag, on or off, that you’re copying from
the old packet, and try to understand the effect of that flag. It’s
possible one (or more) flag value is inappropriate, particularly if
you’re queuing.Fourth, and now I’m grasping at straws, I’ve not used NdisTransferData
in my own code (as opposed to what passthru employs). If you have a
reason to suspect that NdisTransferData is not working the way you
expect, you might look at alternative mechanisms for copying packet
data, such as UTILReadOnPacket (see
http://www.ndis.com/papers/ndispacket/readonpacket.htm) or e100DumpPkt
in offload.c in the DDK’s \src\network\ndis\e100bex.–
If replying by e-mail, please remove “nospam.” from the address.James Antognini
Windows DDK MVP
You are currently subscribed to ntdev as: michal.vodicka@st.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com