Using LabVIEW for packet sniffing and IP spoofing

[mteverestand]

I'm working on testing a product that has two processors that communicate over UDP on Ethernet. Both processors and the tester have unique static IPs on the network. I can stop either processor from sending messages to the other processor. I want to be able to use the tester to send messages that appear to be from processor 1 to processor 2, and vice versa. I would also like to be able to look at the messages the processors are sending to each other even though they don't go to my IP address.

I have seen an NI library for WinPcap (https://forums.ni.com/t5/Example-Code/Ethernet-Packet-Sniffer-Utility-Using-WinPcap-Functions/ta-p/3...), but the library didn't work with 64 bit LabVIEW. Also, the front page of WinPcap's website implies that it's been deprecated for a while. It looks like I'll have to write labview code that calls .dlls from a packet sniffer, but I'm not sure where to even find one that can also send from IP addresses that aren't my computer's. Is that even possible without extra hardware?

Thanks for any help.

[Mark_Yedinak]

I have not played with trying to do this from LabVIEW itself but you would need to make calls to the current WinPCap library. You can send packets that are not from your PC using WinPCap. The addresses would need to be on the same subnet or the will either get dropped or they will get routed out the default gateway. If you are using the IP Address of one of your devices you would need to be careful that both your test application and that device are not running at the same time or you will have duplicate IP Addresses on the network which is not a good thing.

[altenbach]

---

@mteverestand wrote:

but the library didn't work with 64 bit LabVIEW.

What's wrong with using 32bit LabVIEW?

---

@mteverestand wrote:

 I would also like to be able to look at the messages the processors are sending to each other even though they don't go to my IP address..

---

You would need special hardware. Typical unmanaged switches will only send out unicasts on the ports that connects to the correct endpoints. Do you have that? (I still have an old hub, but it's only 10Mbps|half-duplex, of course :D)

---

@mteverestand wrote:

I want to be able to use the tester to send messages that appear to be from processor 1 to processor 2, and vice versa. I would also like to be able to look at the messages the processors are sending to each other even though they don't go to my IP address.

---

That really depends on how authentication, encryption, etc. is made by the two devices. Knowing the specs, you can always write a simple program that mimics processor 1 using plain LabVIEW (Send messages and receive responses, etc.). Nothing special needed. (Of course if processor 1 is on the network at the same time, their IP and MAC addresses need to be different).

[Mark_Yedinak]

---

@altenbach

---

@mteverestand wrote:

 I would also like to be able to look at the messages the processors are sending to each other even though they don't go to my IP address..

---

You would need special hardware. Typical unmanaged switches will only send out unicasts on the ports that connects to the correct endpoints. Do you have that? (I still have an old hub, but it's only 10Mbps|half-duplex, of course :D)

Not necessarily. I reply traffic that was captured from other networks via my PC. You can do this if you don't care if you get a response back. Though the IP addresses do need to be on the same subnet otherwise the switches will route them to the primary gateway.

[altenbach]

---

@Mark_Yedinak wrote:
Not necessarily. I reply traffic that was captured from other networks via my PC. You can do this if you don't care if you get a response back. Though the IP addresses do need to be on the same subnet otherwise the switches will route them to the primary gateway.

---

I am talking about receiving (i.e. monitoring), sending is a different thing. Switches route based on MAC address and only broadcasts/multicasts typically go out on all ports. Even if you do promiscuous capture, you'll typically only see traffic for your PC, plus the various ..casts.

Managed switches can sometimes be configured with monitoring ports. In the past there were tricks to force unmanaged switches into promiscuous mode by bombarding them with a sufficient number of MAC addresses to exhaust their table. 🙂

[mteverestand]

Thank you everyone for your replies! I'll try using the WinPcap .dll files for As far as your questions go: -unfortunately my setup is already pretty heavily invested in 64 bit labview. -I think I can convince the Ethernet switch internal to the product to forward UDP messages in both directions to my hardware (promiscuous mode?), which I can then look at using WinPcap. If I can't, I've got some big issues that can't be solved here. -The format of the messages is standardized, so I can easily set the UDP payload. The problem is the lower level connections. -I can stop each node from sending to the other node, but I don't think I can block them from sending entirely. Will it cause IP conflicts if I'm sending from processor 1's IP to processor 2's IP if there is no other traffic from processor 1 to processor 2, but processor 1 is still using its IP to send to other IPs? Thank you again for your help.

[Mark_Yedinak]

You cannot have the same IP address for two different devices on a single network. It simply does not work. The IP addresses are tied to MAC addresses and MAC addresses MUST be unique on a network. A single MAC address can have multiple IP addresses but a single IP address can only be mapped to a single MAC address.

[Marco-PI]

Hi mteverestan. Were you finally able to use WinPcap on LabView 64 bit? I need to port an old project that used the lvpcap.dll library but I have the following error:

 

as foreseen... 

I don't know if and when the IT dept. of my company will install on my workstation a 32 version of labview, therefore I was wondering if you found a solution for the 64 bit one. I looked after it in the internet but without success.

Thank you,

Marco

[billko]

You're not in control of your development environment?  That's terrible.  😞  It is always recommended to install LV 32-bit unless you absolutely need the extra memory space that LV 64-bit provides.