[Winpcap-users] Problem with automatic modification of the length/type field of mac frames

Guy Harris guy at alum.mit.edu
Mon Jul 31 02:05:22 GMT 2006


Eduardo Escudero Sánchez wrote:
> The problem is that i dont use the winpcap library to send packets, i 
> use packet.dll.

...the API for which is *NOT* guaranteed to remain the same between 
WinPcap releases, so be aware that a future WinPcap release could break 
your program.

> To be more precise, i use the packetsendpacket function 

So does pcap_inject_win32(), called both by pcap_inject() and 
pcap_sendpacket().  It does

	PacketToSend=PacketAllocatePacket();

	if (PacketToSend == NULL)
	{
		snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "send error: 
PacketAllocatePacket failed");
		return -1;
	}

	PacketInitPacket(PacketToSend,(PVOID)buf,size);
	if(PacketSendPacket(p->adapter,PacketToSend,TRUE) == FALSE){
		snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "send error: PacketSendPacket 
failed");
		PacketFreePacket(PacketToSend);
		return -1;
	}

	PacketFreePacket(PacketToSend);

> and i pass to it the frame already set up as an array of bytes.

So do you use PacketAllocatePacket() and PacketInitPacket()?

If so, what size value do you pass PacketInitPacket()?

You should be passing it the *actual* length of the packet, *NOT* 
including the length of the padding (let the OS add the padding!).  That 
length should, of course, include the length of the 802.3 header (but, 
as the CRC is added by the network adapter, the length, and the data, 
shouldn't include the CRC).

> I've 
> seen the code of PacketSendPacket and its only an invocation of 
> kernel32.dll WriteFile function so it should be something with 
> relationship of teh operative system maybe,what do you think? i really 
> need to get this problem solved , can you imagine what could be happening?

WriteFile() ends up calling the WinPcap driver in kernel mode.  That 
ends up with the packet being queued up to be sent, via a call to 
NdisSend().

Something in between the WriteFile() call and the network adapter is 
adding the padding.  As I've already indicated, it's probably the driver 
code (or common 802.3 code - the driver's probably a miniport driver, 
but I don't know what the architecture of any code surrounding it would 
be, e.g. whether there's any code that would be shared by all Ethernet 
miniport drivers).


More information about the Winpcap-users mailing list