WinPcap performs no buffering on the sent packets, this means that each
packet is sent individually and the length of one of them doesn't affect the
others.
PacketSendPacket() (in WinNTx) has the following body:

BOOLEAN PacketSendPacket(LPADAPTER AdapterObject,LPPACKET lpPacket,BOOLEAN
Sync)
{
    DWORD        BytesTransfered;

    return
WriteFile(AdapterObject->hFile,lpPacket->Buffer,lpPacket->Length,&BytesTrans
fered,NULL);
}

It takes the length of the packet and uses it as the nNumberOfBytesToWrite
parameter of writefile() system call that delivers the packet to the driver.
Notice that writefile() is blocking.
To summarize: you should be able to chance lpPacket->Length without
affecting previous packets.

Loris

----- Original Message -----
From: "J. Errett Hogrefe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, April 09, 2002 4:23 PM
Subject: [WinPcap-users] Controlling transmit packet length dynamically


Is it possible to dynamically change the length of the packets
transmitted to
the network?  I notice that the TX packet length is governed by the
buffer length
parameter in the function: PacketInitPacket.  If one uses this function
to set
the TX packet length, what happens to the packets that have already been

sent to the DRIVER via the PacketSendPacket function?  The only way that
I could see from the online documents to change the TX packet length is
described below:

PacketInitPacket(lpTxPacket, txPacketBuff, 60); /* Set the length to 60
Bytes */
PacketSendPacket(lpAdapter,lpTxPacket,TRUE); /* Send the packet */
PacketInitPacket(lpTxPacket, txPacketBuff, 120);
     /* Set the length to 120 Bytes - Are we guaranteed that the packet
has been transmitted yet?
        Are we guaranteed that only 60 bytes of the first packet gets
transmitted? */

I would like to be able to dynamically change the packet length without
affecting
the packets already in the driver queue, and without waiting (no "Sleep"
calls, etc.) -
is this possible with the winpcap libraries and API?

Thank you for your help.

Errett Hogrefe




Reply via email to