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

[Guy Harris]

Eduardo Escudero Sánchez wrote:
> So then as far as i have understand is the operative system the one who 
> is modifying me the length field. I pass to PacketInitPacket the length 
> of all the MAC frame wgich includes: header with the source and 
> destination addresses(12 bytes), length /type field which are two bytes, 
> the data which i want to send (suppose three bytes) and the pad (43 
> bytes). In the length / type field i put a value of three (which is the 
> length of the data) but i pass to packetsendpacket a length value of 60 
> (the length of all the frame);
> If i have understand you you are saying me the i must not put the pad by 
> myself, i must put only the data and then the operative system will put 
> the pad for me.

Yes.

And, in addition, when you tell packet.dll how much data you're 
supplying, you tell it an amount that does *NOT* include the padding. 
I.e., you do *NOT* pass a length value of 60 to PacketInitPacket(), you 
pass a length value of 12+2+3 = 17.

(At least in WinPcap 3.1 and 4.0alpha1, you don't pass *any* length 
value to PacketSendPacket(), you just pass it an LPPACKET pointer to a 
structure that's been initialized by PacketInitPacket(); that structure 
presumably contains the length value provided to PacketInitPacket().)

> I already have done that.

You've already passed a length value of 17, *NOT* 60, to 
PacketInitPacket()?  (You're not passing *any* length value to 
PacketSendPacket(), unless you're using a pre-3.1 version of WinPcap.)

> But when the frame is received 
> in the other side its received also without pad. My application has to 
> analize the MAC frame received or sent and its interesant to ensure that 
> the pad field will be there in order to see when the pad needs to be 
> added and when not, do you understand me?

No.  I don't understand at all.

For one thing, I don't understand what you mean by "analyze".

If this is a protocol that that the two processes on the two machines 
are using, then presumably, if the process on the sending machine is 
sending a packet with three bytes of data, three bytes of data are being 
sent using the protocol, and therefore the receiving machine is being 
sent three bytes to process, and should only process those three bytes.

I.e., it should be irrelevant to the application whether there's padding 
in the frame or not, as it will look only at the three bytes of data in 
the packet.  Therefore, the padding doesn't have to be there in order 
for the receiving process to be able to process the packet.

So, if by "analyze" you mean "process the packet for the protocol when 
it's received", the padding doesn't need to be there in order to analyze 
the packet.

As for *sending* the packet, the sending process doesn't add the padding 
- it supplies the packet, without padding, to WinPcap or to packet.dll, 
and that supplies it to the WinPcap driver, and that supplies it to 
NDIS, and that supplies it to the network adapter driver, and the 
network adapter driver adds the padding.  Therefore, it doesn't need to 
add the padding.