On Wednesday, May 19, 2010 at 11:52 PM, "Fish" (David B. Trout)
<f...@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)
> f...@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
f...@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@winpcap.org
https://www.winpcap.org/mailman/listinfo/winpcap-users
