3

We are preparing a product for EMC testing. The product runs Windows Embedded Standard 2009 (compare it with Windows XP) and has 2 NICs, say NIC1 and NIC2.

For the emission test, we need to send data from NIC1 to NIC2. If I assign both NICs an IP address in the same range, I can PING and send/receive data, but data is not transmitted over the crossed cable.

Is there a way (by changing the route table f.e.) to actually send the data from NIC1 to NIC2 over the crossed cable without adding extra hardware?

Housy
  • 143
  • 8
  • We can't answer the question, so we downvote it? At least leave a comment. – Housy Aug 16 '12 at 13:18
  • The saga of rogue down votes continues. All I can say is ignore the down votes. The only reason I can think of is that your question _may_ be out of scope for serverfault. – Chida Aug 16 '12 at 13:23

3 Answers3

2

The simplest solution is probably to use a UDP broadcast. That way, Windows will have to put the data on the wire, since it has no way of knowing that there are no other nodes on the network.

I'm not absolutely certain that Windows won't drop the incoming broadcast packets but it seems unlikely. You might conceivably see two copies of each packet (one sent directly and one sent over the wire) but that seems unlikely too.

Harry Johnston
  • 6,005
  • 4
  • 35
  • 52
1

How about two virtual machines. VM 1 is bridged to the first interface while VM 2 is bridged to the second interface. Send traffic between the VMs that way. I don't know if this is easy in Windows, though.

Another option is to use IPv6 scope local, the addresses that begin with fe80:: (Just tested in Linux and it works there, but I don't have Windows to try with).

Skaperen
  • 1,094
  • 2
  • 11
  • 23
  • +1. My guess would be that Windows is too smart for either of these approaches to work, but they're worth a try. – Harry Johnston Aug 17 '12 at 04:40
  • Had the VM idea too. As for this test I can't use it because there's a lot of other hardware that needs to be tested and this will not work from within a VM. I will still give it a try if the UDP broadcast method fails. – Housy Aug 17 '12 at 04:55
  • Opening a raw socket from a programming language with full capability socket bindings would be a direct approach if you are developing the testing tools. – Skaperen Aug 17 '12 at 05:17
0

You might look into iperf. iperf is designed to test network speeds and performance by sending actual data. It requires a client/server on both sides of the connection though, so depending on the environment, that may or may not help.

http://en.wikipedia.org/wiki/Iperf

http://sourceforge.net/projects/iperf/

Univ426
  • 2,149
  • 14
  • 26
  • I created my own program that listens to a port bound to NIC1 and connects to NIC1 with a socket bound to NIC2. I can send and receive, but the data stays in the machine and doesn't go over the crossed cable (I can even remove the cable, it keeps on working). So with iperf, I will have the same issue. – Housy Aug 16 '12 at 13:06
  • Ah, gotchya. Not saying it's you WouterH, but I usually like comments with my down votes too :S looks like you experienced the same thing up there - here's an upvote for you to compensate ;) – Univ426 Aug 16 '12 at 23:55
  • Have you tried swapping the cables/ensuring the proper use of a crossover or straight cable? Do your ping/ICMP requests come back? – Univ426 Aug 16 '12 at 23:57
  • No it wasn't my downvote, here is my compensating upvote :) Problem is that I can even remove the cable and ping still works. Even the client/ server program continues to work where server bound to IP of NIC1 and client to IP of NIC2 – Housy Aug 17 '12 at 04:49
  • Haha, thanks - that's really bizarre. I've seen some applications we use that indicate data flowing over the wire, even with no wire plugged in. I'm not sure what the mechanism is, but I'll let you know if I find anything. – Univ426 Aug 17 '12 at 12:40