[Winpcap-users] About the value returned by pcap_pkthdr...

[Guy Harris]

Balazs, Monika wrote:
> I've descovered during testing that the structure *pcap_pkthdr* in it's 
> field *len* retains the value of the data received in a call *pcap_next_ex*.
> My problem is that for packages with size lower then 60 *len* retains 
> the value 60, no matter the exact size of the packet that it has been 
> received. Only packets with yotal size grater than 60 have the *len* 
> field valid.

If you're capturing from Ethernet, this is expected behavior for packets 
you receive; packets you receive shouldn't ever *have* a size lower than 60!

The minimum size of an Ethernet packet is 64 bytes, including the 4-byte 
CRC at the end, so the minimum size of a packet without the CRC is 60 
bytes; most Ethernet adapters either don't return the CRC or can be 
configured to return or not return the CRC, and most drivers for the 
latter type of adapter configure them not to return the CRC.

This means that if some packet were to be handed to the Ethernet driver 
to send, and the packet, with the MAC header added (but without the CRC 
added), would be shorter than 60 bytes long, the driver would pad the 
packet to 60 bytes before transmitting it.

> Is there any posibility to find out from where this defaul value 60 is 
> set and could be modified, becouse I have to build an application 
> capable of handling messeges with total size much smaller then 60...

You either need to

	1) use the type/length field of the Ethernet packet as a length field, 
which would require you to use an IEEE 802.2 header after the Ethernet 
MAC header, and probably also use a SNAP header

or

	2) have whatever protocol you're creating for this application include 
a length field

or

	3) otherwise arrange that you can tell how long the packet really is 
(e.g., have other length fields, as the ARP packet format does)

so that you can indicate how long the packet *really* is, without the 
extra padding.