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

[Eduardo Escudero Sánchez]

Sorry if i havent explained me well. The application i'm developing must
show the user how the mac sublayer operates. You can pass it data and you
will see how this artificial MAC sublayer constructs a mac frame with the
data you have passed to it. Then , once the frame is built , this entity
would send the built frame using tha packet.dll API. I expected the API to
deliver my packet as i have set up it. This means that if i build a frme
with two mac addrsses, a length /type field and data and some pad i expected
to receive in the other instance of my application, which is running in the
destination machine, exactly the same bytes i sent. But i encountered the
problem of the length /type field modification which i was talking about
before. The other machine running my application must receive all the data,
including the pad , because it expects to receive it.(This is because i was
thinking that the data i was sending will arrive as i send it tto the other
side) ¿do you understand me now?. Then the remote application instance would
look at the frame and tell the user that a mac frame has been received with
two addresses, a length type field, some data and a pad .
If something is adding the pad transparently and removing it in the remote
machine the user of my application wont see this pad-function, and i wanted
him to see it. That's why i need to send and receive mac frame with pad. One
solution is to add it artificially on the sending and receiving to tell the
user : ey ,here some pad has been added. And then send the data without pad
as you say.
I don't know if im explaining me well, i have difficulties on explaining
this things in english, sorry.


2006/7/31, Guy Harris <guy at alum.mit.edu>:
>
> 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.
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20060731/28075bcf/attachment.htm