#WIRESHARK REPLAY PCAP CODE#
#WIRESHARK REPLAY PCAP MAC#
#WIRESHARK REPLAY PCAP WINDOWS#

If there are packets in the pcap which are larger than the default MTU on the interfaces of the replay machine, you need to increase the MTU on those interfaces. The two interfaces are cabled directly to the Inside and Outside ports on the PacketShaper. Packet captures taken on a PacketShaper are in this format and Wireshark or other capture tools can be used as long as the capture is saved in libpcap format.Ī Linux machine with two available interfaces is needed. The packet capture needs to be in libpcap format. It does not work very well if one wants to shape traffic because packets are sent at a deterministic rate by the replay machine. (As an aside, I did also capture the replayed packet from Colasoft PacketPlayer and it too appears identical to the source packet).Replaying captures is useful for many types of classification problems or adding background load on a PacketShaper. I did not initially try that route as I was concerned with generating the packet on the same machine which is listening for it. This appears to have the same apparent results (i.e.

#WIRESHARK REPLAY PCAP WINDOWS#

I also saw mention of a Windows program, ' Colasoft PacketPlayer', which I tried - running on the same machine as my Python client. Here on stackoverflow, I did find this thread which seems to be an identical problem, however none of the solutions presented within helped (including changing the rp_filter parameter). However, my Python program still stoically sits there waiting at: data, address = sock.recvfrom(1024) A diff on the byte contents of each packet yields no differences.

#WIRESHARK REPLAY PCAP MAC#

The contents of both the source packet (sent by tcpreplay) and the received packet (grabbed by Wireshark) appear identical - including the source and destination MAC addresses and the checksums. To my disappointment, my Python program (on the Windows machine) did not receive the incoming packets.īack on the Windows machine, I fired up Wireshark again and captured the 'replayed' packet coming from the Ubuntu machine - so it appears the packet did make it out of my Ubuntu machine and into my Windows one.

I then attempted to replay that pcap file (on the Ubuntu machine) as follows: So, on the Windows machine, I captured a UDP multicast packet stream using Wireshark and saved to a pcap file which I then copied to the Ubuntu machine. I figured if I could catch a snippet of UDP broadcasts from that program, I should be able to replay at leisure without having to run that resource hog.

#WIRESHARK REPLAY PCAP CODE#

So, moving forward, I decided it would be great to be able to work on the Python code without having the commercial program always running in the background hogging up resources. I have a lot of work yet to do on the contents of those packets after they are received, but that isn't important for this issue. When I run the commercial program, my Python code correctly consumes the incoming packets and all seems to be working fine. On the Windows machine I have a Python program I wrote which listens for UDP multicast packets on port 5110 (this is dictated by the source of the UDP stream which is a commercial program). One machine (running tcpreplay) is running Ubuntu 20.04, the other machine is running Windows 10. I have two machines on my local (wired) network connected through one unmanaged switch. I'm having no joy in getting a replayed UDP Multicast packet to be 'seen' by a client program on a different machine.

Wireshark replay pcap