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

[Eduardo Escudero Sánchez]

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. I already have done that. 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?
One solution could be to send the data the way you are telling me without
the pad been added and then my analizer adds artificially the pad when it
has to analize the frame. This way i could show the pad field in the frame
analysis.


2006/7/31, Guy Harris <guy at alum.mit.edu>:
>
> Eduardo Escudero Sánchez wrote:
> > The problem is that i dont use the winpcap library to send packets, i
> > use packet.dll.
>
> ...the API for which is *NOT* guaranteed to remain the same between
> WinPcap releases, so be aware that a future WinPcap release could break
> your program.
>
> > To be more precise, i use the packetsendpacket function
>
> So does pcap_inject_win32(), called both by pcap_inject() and
> pcap_sendpacket().  It does
>
>        PacketToSend=PacketAllocatePacket();
>
>        if (PacketToSend == NULL)
>        {
>                snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "send error:
> PacketAllocatePacket failed");
>                return -1;
>        }
>
>        PacketInitPacket(PacketToSend,(PVOID)buf,size);
>        if(PacketSendPacket(p->adapter,PacketToSend,TRUE) == FALSE){
>                snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "send error:
> PacketSendPacket
> failed");
>                PacketFreePacket(PacketToSend);
>                return -1;
>        }
>
>        PacketFreePacket(PacketToSend);
>
> > and i pass to it the frame already set up as an array of bytes.
>
> So do you use PacketAllocatePacket() and PacketInitPacket()?
>
> If so, what size value do you pass PacketInitPacket()?
>
> You should be passing it the *actual* length of the packet, *NOT*
> including the length of the padding (let the OS add the padding!).  That
> length should, of course, include the length of the 802.3 header (but,
> as the CRC is added by the network adapter, the length, and the data,
> shouldn't include the CRC).
>
> > I've
> > seen the code of PacketSendPacket and its only an invocation of
> > kernel32.dll WriteFile function so it should be something with
> > relationship of teh operative system maybe,what do you think? i really
> > need to get this problem solved , can you imagine what could be
> happening?
>
> WriteFile() ends up calling the WinPcap driver in kernel mode.  That
> ends up with the packet being queued up to be sent, via a call to
> NdisSend().
>
> Something in between the WriteFile() call and the network adapter is
> adding the padding.  As I've already indicated, it's probably the driver
> code (or common 802.3 code - the driver's probably a miniport driver,
> but I don't know what the architecture of any code surrounding it would
> be, e.g. whether there's any code that would be shared by all Ethernet
> miniport drivers).
> _______________________________________________
> 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/91cf9eb9/attachment-0002.htm