[Winpcap-users] Problem with automatic modification of
the length/type field of mac frames
guy at alum.mit.edu
Mon Jul 31 09:39:09 GMT 2006
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.
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
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.
More information about the Winpcap-users