[Winpcap-users] pcap_sendpacket to local adaptor (Sending tothelocal machine)

[Gianluca Varenni]

--------------------------------------------------
From: "Mark Pizzolato - WinPCap-Users" 
<winpcap-users-20040408 at subscriptions.pizzolato.net>
Sent: Wednesday, June 02, 2010 12:33 PM
To: <winpcap-users at winpcap.org>
Cc: ""Fish" (David B. Trout)" <fish at infidels.org>
Subject: Re: [Winpcap-users] pcap_sendpacket to local adaptor (Sending 
tothelocal machine)

> On Wednesday, May 19, 2010 at 11:52 PM, "Fish" (David B. Trout) 
> <fish at infidels.org> wrote:
>
>> Mark Pizzolato wrote:
>>
>> [...]
>> > In general, a host never sends packets on a LAN to itself.
>>
>> In general.
>>
>>
>> > NICs are not designed to do that.
>>
>> Misleading. NICs are designed to send whatever data you want them to
>> send.
>>
>> Whether the Ethernet packet just so happens to have the NIC's MAC in the
>> Ethernet packet's destination MAC field or not is immaterial. The NIC 
>> should
>> send whatever data you tell it to send. (That is to say the packet SHOULD
>> make it "onto the wire. If it doesn't then it's malfunctioning. Buy a new
>> NIC.)
>>
>>
>> > Pcap_sendpacket() merely asks the NIC to do what it normally does and
>> > send the packet out.
>>
>> Correct. And whatever value is in the target MAC field of the packet 
>> being
>> sent shouldn't matter. The packet should get sent. Period.
>
> I never said anything to the contrary.
>
>> <snip remainder>
>>
>> FWIW, my software[1] successfully does what Kyle is currently having 
>> trouble
>> doing and has been successfully doing it now for many years now (since
>> WinPCap version 2.x on many different systems around the world each using
>> many different types and models (brands/manufacturers) of NICs) with
>> absolutely no problems whatsoever. It works fine.
>>
>> The only reason I can think of as to why Kyle's efforts are working for 
>> him is
>> *maybe* because maybe the NIC wasn't set to promiscuous mode
>> beforehand.
>> Not sure if that's a requirement for this technique to work or not, but 
>> FWIW
>> that's the way my software does it.[2]
>>
>> Hope that helps.
>
> Actually it certainly does since your success cause me to question my base 
> assumptions which are:
>
>    There is no requirement for a NIC to receive packets which it sends, I 
> believe
>    that very few do.  The network stacks of the system are designed to 
> internally
>    "loop back" any packets which might be destined to the originating 
> system
>    BEFORE the packets are presented to the NIC (or even anything at layer 
> 2).
>    Pcap_sendpacket() sidesteps the network stacks and directly puts the 
> packet
>    on the wire.  This is fine whenever the destination is someplace out on 
> the
>    LAN, however when the destination is the local (host) computer, the
>    destination MAC address will be the hardware mac address of the local 
> NIC.
>    Since most NICs aren't designed to receive packets which they send 
> which
>    have their own MAC address the packets will be transmitted on the wire,
>    BUT they won't be received by the NIC's receive side and they therefore
>    won't make it to the host systems's IP stack.
>
> Well, these assumptions ARE correct on Non-Windows platforms (using 
> libpcap).  However, since it works for you they clearly are NOT correct on 
> Windows.  With an network interface using WinPcap in promiscuous mode, 
> packets sent with pcap_sendpacket() are indeed received by the host 
> system's network stack.

On Windows sent packets are actually looped back by NDIS itself if the 
protocol driver sets its hardware filter to promiscuous or "all local". A 
NIC miniport driver can opt to loop packets back on its own. If it does 
that, it tells NDIS that he will take care of looping packets back. There is 
no magic in it. If a protocol driver (WinPcap or any other protocol driver 
like TCP/IP) receives the packets sent by the host itself, it's because it 
set his own hardware filter to promiscuous or all local.

Have a nice day
GV

>
>>
>> --
>> "Fish" (David B. Trout)
>>  fish at softdevlabs.com
>>
>> [1] http://www.softdevlabs.com/ctciw32
>>
>> See specifically,
>> http://www.softdevlabs.com/Hercules/ctci-w32-readme.html#overview
>>
>> [2] Our product (Hercules, a mainframe emulator
>> (http://www.hercules-390.org)) runs as a virtual machine on the Windows
>> host, and needs to be able to exchange packets with it (or any other 
>> system
>> really). My CTCI-W32 software (scheduled to be renamed to CTCI-WIN)
>> accomplishes this by having WinPCap set the adapter into promiscuous mode
>> and monitoring for any packet whose destination MAC matches that of the
>> virtual NIC's (or has the all stations broadcast bit on). If so, the 
>> packet is
>> returned back to the virtual machine (i.e. Hercules) and the guest 
>> operating
>> system (running under Hercules) receives it. Packets that the guest 
>> machine
>> wants to send Hercules pass on to my code which simply does a WinPCap
>> sendpacket.
>>
>> And as I said this all works fine and HAS been working fine for many 
>> years.
>
> My experience comes from a very similar place.  I'm one of the authors of 
> the network layer code for Bob Supnik's simh simulator family 
> (http://simh.trailing-edge.com).  The simulators with network support are: 
> VAX, PDP11, and PDP10.
>
> We've also been using WinPcap since the Version 2.x days.  We use a 
> promiscuous mode pcap interface to implement the receive side of our 
> processing and pcap_sendpacket() to send packets.  Since we're using the 
> pcap layer for this functionality, our implementation works on windows as 
> well as essentially any platform which has working libpcap.
>
> Our experience on both Windows AND the various *nix platforms was that you 
> CAN use this model to talk to all other systems on the LAN, but you CAN'T 
> use it doesn't to talk the host system's IP stack without some sort of 
> bridge monkey business like I mentioned (this bridge model works on BOTH 
> the Windows and *nix platforms).  A simpler approach that most folks use 
> is to dedicate an extra NIC just to our a simulator and connect that NIC 
> to the same LAN.
>
> Since your experience talking to the local host seems to be successful 
> while ours wasn't, I'm was extremely motivated to avoid the bridge monkey 
> business or extra NICs on windows hosts.
>
> After some digging I determined the reasons why host to guest networking 
> wasn't working  on windows for us:
>  1)  Host to guest IP communications start with an ARP request.  This 
> request is sent to the NIC as a 42 byte frame which the NIC would expand 
> to the minimal Ethernet frame size as it was transmitted. The code in our 
> simulated network adapter saw this 42 byte packet as a RUNT and discarded 
> it.  Our receive code has now been fixed to perform the expansion that NIC 
> would have actually done for these cases.
>  2) Once #1 was fixed, on some systems I observed that Host to guest ICMP, 
> UDP and TCP packets were being received by the network stack in the 
> simulated system, but the stack was discarding these packets since they 
> had invalid/garbage IP, ICMP, UDP, and TCP checksums.  This issue was due 
> to the fact that all of these frames were being sent to the host NIC with 
> the Windows IP stack assuming that the NIC would perform the various 
> checksum computations due to the TOE (TCP Offload Engine) capabilities of 
> the NICs on these systems.  Our receive code has now been modified to 
> perform these checksum computations for all IPv4 frames originating from 
> the host.
>  3) Once #2 was fixed, there were still some situations where host to 
> guest traffic didn't arrive.  These cases turned out to be when large 
> amounts of data was being sent via TCP and the NIC had the TOE LSO (Large 
> Send Offload) aka TSO (TCP Segment Offload) features available and 
> enabled.  Our receive code has now been modified to perform the 
> segmentation activities as large TCP packets are received from the host 
> and small segments are dropped into the simulated NIC's receive queue. 
> This segmentation capability also enables simulated systems to exist on a 
> LAN segment where Jumbo frames are in use.
>
> Thank you very much David for helping me see the light here.
>
> - Mark Pizzolato
>
> By the way, your website http://www.softdevlabs.com seems offline (as does 
> your fish at softdevlabs.com email address), I was able to look at some of 
> your stuff in Google's cache though.
>
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users