Re: packet does not get to tcp ip

After further investigation I think that I know the cause of the
problem:

I used NdisMIndicateReceivePacket with a packet that is composed from
several buffers.
So I think that the TCP/IP protocol ReceivePacketHandler could not
handle this while the sniffer could.
The reason the packet is composed from several buffers is because the
driver does not drive a real ethernet NIC but only present itself to
NDIS like an ethernet driver. So when I get a buffer to indicate to
NDIS I build a packet which is composed from the buffer I got and
another buffer which contain a fix ethernet header.

According to msdn on NdisMIndicateReceivePacket:
"The first buffer in the packet must contain the amount of data
specified by the lookahead setting plus the data size of the MAC
header"

Now this raise a problem for me:
If I get multi buffers (whose total length is less than the ethernet
MTU)
I have several possibilities as I see it:

1. Indicate each buffer to NDIS in its own packet containing only one
buffer - this seems to me inefficient

2. Copy all the buffers to a single buffer and indicate the new buffer
to ndis in a single packet - this seems to me even less efficient

3. Override the lookahead setting to be 0 so the first buffer will
contain only the ethernet header - I am not sure that the overriding is
allowed, actually I am not sure what is the meaning of the lookahead
buffer (OID_GEN_RECEIVE_BLOCK_SIZE) is it enough that I only answer 0
for this oid query?

Can anyone suggest me what is the preffered way?

Thanks
Miki




miki wrote:
Hi,

I have this strange problem:

I am trying to do a ping through the NIC connected to my ethernet
miniport driver.
With a sniffer (ethereal) on the NIC I can see the icmp request and
also the icmp reply packets both seems correct as far as I can see, yet
the ping application failed with timeout.
This happen also when I try tcp application like ftp.

It seems like the packets the driver indicate to NDIS does not reach
the tcp ip protocol driver (or maybe they do and the protocol driver
drop them for some reason) so the the application at the end point does
not receives them.

The firewall rule on the interface are permit all.

Where should I look for the trouble?

How can I gather more information - for example how can I know if the
tcp ip gets the packet after I indicate it to ndis? how can I know if
it drop it?

Thanks
Miki

.

Relevant Pages

  • Re: Question about modifing the NDIS packet?
    ... packet FROM a miniport BACK of the net. ... If your driver is an intermediate ... you driver changes the length of the ndis packet buffer - here you ... your driver is not a registered ndis driver. ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: NDIS ProtocolReceive - Is It Dead Yet?
    ... Certainly the NDIS 5 NDISPROT sample includes logic to deal with the abomination. ... The "unnecessary" buffer allocation is due to a fault in NdisTransferData. ... NdisTransferData does not feature an offset into the destination packet. ...
    (microsoft.public.development.device.drivers)
  • Re: Interesting TCP behaviour with large sends/small buffers
    ... My current workaround is simply setting the send buffer to a larger ... The server, upon connection, sends a configurable number of bytes to ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)
  • Re: Question about modifing the NDIS packet?
    ... I was able to sucessfully modify the packet. ... If your driver is an intermediate ... > allocate the appropriate packet buffer, ... your driver is not a registered ndis driver. ...
    (microsoft.public.windowsxp.device_driver.dev)
  • Re: Interesting TCP behaviour with large sends/small buffers
    ... The server, upon connection, sends a configurable number of bytes to ... I set the client's receive buffer size to 1MBps, ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)