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

[Mark Pizzolato - WinPCap-Users]

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.
 
> 
> --
> "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.