- This topic has 1 reply, 2 voices, and was last updated 17 years, 1 month ago by
.
-
Posts
-
If I want to inject self-crafted raw Ethernet frames into the network, I use the WinPkFilter function SendPacketToAdapter() which issues a IOCTL_NDISRD_ADAPTER_QUEUE_SIZE call to the ndisrd driver. This works fine if I send just a few packets. But if I have to send a larger amount of packets, e.g. 1000 packets at once, the greatest part of the packets is never sent to the network though the return code of SendPacketToAdapter() indicates each time a successful operation.
It is clear what happens here: The SendPacketToAdapter() function just passes the packet to the ndisrd driver and returns immediately. It does not block until the packet is actually sent by the adapter. The ndisrd driver seems to have a queue for outgoing packets which quickly overflows when dispatching a large amount of packets with SendPacketToAdapter().
Why does the SendPacketToAdapter() call not block when the outgoing packet queue of the ndisrd driver becomes full? How can I make it block if I want to send a large pile of self-crafted packets at once and must be sure that they were actually sent by the network adapter?
It is interesting to note that there are no packet losses when running the PassThrough demo where the packets to be sent with SendPacketToAdapter() come from an application. Even if some application sends TCP data at a high rate, there aren’t any retransmissions, i.e. each packet passed to the adapter is actually sent and no packet got lost.
Many thanks for your help in advance!
—-
Maxedited:
I also noticed that the packets get dropped only if they are large enough. When dispatching 1000 packets with a length of 1000 bytes, only 150 – 200 packets get actually sent. But when dispatching 1000 packets with a length of 250 bytes, all 1000 packets are actually sent by the network adapter.
Well, WinpkFilter was designed mainly for packet filtering solutions but not for spoofing. Interface functions for sending packets are designed as non-blocking for better performance and sending packets through the WinpkFilter at the rate above the network bandwidth causes packet loss (this caused by network limits, not the WinpkFilter internal queue size). Basically you can change your application to send packets on some fixed realistic rate to avoid packet loss. This can be implemented with a waitable periodic timer, which callback routine would calculate time passed since last fireup and how many data should be passed during this time at the given rate. Then send calculated amount of data on the network and requeue the timer. Such approach will allow you to send packets on the network at a given rate which should be chosen below the real network bandwidth.
- You must be logged in to reply to this topic.