<div>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 .
<div>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.
<div>I don't know if im explaining me well, i have difficulties on explaining this things in english, sorry.<br><br> </div>
<div><span class="gmail_quote">2006/7/31, Guy Harris <<a href="mailto:firstname.lastname@example.org">email@example.com</a>>:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Eduardo Escudero Sánchez wrote:<br>> So then as far as i have understand is the operative system the one who
<br>> is modifying me the length field. I pass to PacketInitPacket the length<br>> of all the MAC frame wgich includes: header with the source and<br>> destination addresses(12 bytes), length /type field which are two bytes,
<br>> the data which i want to send (suppose three bytes) and the pad (43<br>> bytes). In the length / type field i put a value of three (which is the<br>> length of the data) but i pass to packetsendpacket a length value of 60
<br>> (the length of all the frame);<br>> If i have understand you you are saying me the i must not put the pad by<br>> myself, i must put only the data and then the operative system will put<br>> the pad for me.
<br><br>Yes.<br><br>And, in addition, when you tell packet.dll how much data you're<br>supplying, you tell it an amount that does *NOT* include the padding.<br>I.e., you do *NOT* pass a length value of 60 to PacketInitPacket(), you
<br>pass a length value of 12+2+3 = 17.<br><br>(At least in WinPcap 3.1 and 4.0alpha1, you don't pass *any* length<br>value to PacketSendPacket(), you just pass it an LPPACKET pointer to a<br>structure that's been initialized by PacketInitPacket(); that structure
<br>presumably contains the length value provided to PacketInitPacket().)<br><br>> I already have done that.<br><br>You've already passed a length value of 17, *NOT* 60, to<br>PacketInitPacket()? (You're not passing *any* length value to
<br>PacketSendPacket(), unless you're using a pre-3.1 version of WinPcap.)<br><br>> But when the frame is received<br>> in the other side its received also without pad. My application has to<br>> analize the MAC frame received or sent and its interesant to ensure that
<br>> the pad field will be there in order to see when the pad needs to be<br>> added and when not, do you understand me?<br><br>No. I don't understand at all.<br><br>For one thing, I don't understand what you mean by "analyze".
<br><br>If this is a protocol that that the two processes on the two machines<br>are using, then presumably, if the process on the sending machine is<br>sending a packet with three bytes of data, three bytes of data are being
<br>sent using the protocol, and therefore the receiving machine is being<br>sent three bytes to process, and should only process those three bytes.<br><br>I.e., it should be irrelevant to the application whether there's padding
<br>in the frame or not, as it will look only at the three bytes of data in<br>the packet. Therefore, the padding doesn't have to be there in order<br>for the receiving process to be able to process the packet.<br><br>So, if by "analyze" you mean "process the packet for the protocol when
<br>it's received", the padding doesn't need to be there in order to analyze<br>the packet.<br><br>As for *sending* the packet, the sending process doesn't add the padding<br>- it supplies the packet, without padding, to WinPcap or to
packet.dll,<br>and that supplies it to the WinPcap driver, and that supplies it to<br>NDIS, and that supplies it to the network adapter driver, and the<br>network adapter driver adds the padding. Therefore, it doesn't need to
<br>add the padding.<br>_______________________________________________<br>Winpcap-users mailing list<br><a href="mailto:Winpcapfirstname.lastname@example.org">Winpcapemail@example.com</a><br><a href="https://www.winpcap.org/mailman/listinfo/winpcap-users">