Someone can help me??

Andre Siqueira escreveu:
> I'm not "locking" the user buffer because I allocate memory and
> then copy the user buffer with NdisMoveMemory.
>
> I don't use NetBuffers because I want the code run in NDIS >= 5.0,
> so I can have the same driver for windows 2000/ XP/ 2003/ Vista.
>
> The problem is that when I call NdisSendPackets, the function
> SendCompleteHandler is called with the status
> NDIS_STATUS_SUCCESS, even the packet didn't go to the
> network.
>
> Thanks,
>
> Andre.
>
>
> Pavel A. escreveu:
>
>> Do you *lock* the user buffer?
>> Do you use NetBuffers instead of old ndis packets?
>>
>> --PA
>>
>>
>> "Andre Siqueira" wrote:
>>
>>> Hello,
>>>
>>> I'm porting my intermediate driver to windows vista.
>>> But I'm having I problem. The function NdisSendPackets do no work in
>>> some
>>> situation.
>>>
>>> When I'm passing packets up and down through my driver it works OK,
like
>>> passthru example. But when I want to send a packet that comes from
>>> the user
>>> level with IOCTL, the function NdisSendPackets do not work, but
>>> returns with
>>> NDIS_STATUS_SUCCESS in the SendCompleteHandler function.
>>>
>>> I create my device with NdisMRegisterDevice, and set the flag
>>> DO_BUFFERED_IO.
>>>
>>> When the user write in this device, I get the buffer with
>>> buf = irp->AssociatedIrp.SystemBuffer;
>>>
>>> then, I call NdisAllocatePacket, NdisAllocateMemoryWithTag,
>>> NdisAllocateBuffer, NdisChainBufferAtFront and NdisMoveMemory before
>>> NdisSendPackets.
>>>
>>> is there something I'm doing wrong?
>>>
>>> thanks,
>>>
>>> André.
>>
>>
>>

Andre Siqueira wrote:
[..]
> > The problem is that when I call NdisSendPackets, the function
> > SendCompleteHandler is called with the status
> > NDIS_STATUS_SUCCESS, even the packet didn't go to the
> > network.

Hmm, what's wrong about NDIS_STATUS_SUCCESS? Isn't this how one would
usually expect NdisSendPackets() to work?

I guess you are somewhat confused about the fact that you see
NDIS_STATUS_SUCCESS *although* the frame described by the NDIS_PACKET
does *not* actually go to the network, right?

This is called a "lying send" but is ok and common practice for network
drivers. Just because there is usually no use in the information
whether the network driver was actually able to send a frame to the
network or not.

(Think about it a little: The fact that a frame was *sent* out to the
*local* network (LAN) does not also mean it got *received* by some
other station(s), not to mention a "remote destination" in a WAN, e.g.
Internet. In general, it is the responsibility of higher level protocol
drivers to ensure data delivery by using mechanisms such as timeouts
and retries. This is true although some network media allow for layer-2
delivery status, e.g. WLAN or Token-Ring/FDDI).

Stephan