How to replay a network trafic of PGM protocol using tcpreplay?

0
votes

I want to multicast a network trafic to specific multicast destination IP address. In input pcap file PGM protocol packets are available.

I'm performing following steps of tcpreplay to multicast a pcap file over a network-

  1. rewriting destination and source mac address available in pcap file

    tcprewrite --enet-dmac=Destination Mac Address --enet-smac=Source Mac Adress --infile=input.pcap --outfile=output.pcap

  2. Obtain a cache file, which is used while rewriting the IP addresses.

    tcpprep --auto=bridge --pcap=output.pcap --cachefile=input.cache

  3. Rewrite the IP addresses

    tcprewrite --endpoints=Destination multicast IP Adress:Source interface IP Address --cachefile=input.cache --infile=output.pcap --outfile=newoutput.pcap

  4. Finally multicast newoutput.pcap.

    sudo tcpreplay --mbps=2.0 --intf1=eth0 newoutput.pcap

But in step 1 I'm facing following error -

Warning in tcprewrite.c:post_args() line 225: testsg.pcap was captured using a snaplen of 9216 bytes. This may mean you have truncated packets.

In other side I'm trying to capture using following command -

tcpdump -n "dst host Destination multicast IP Adress and dst port Destination port number"

But not even one packet also get captured at other side.

Previously I'm sending UDP protocols capture pcap file and at that time I'm getting all the packets correctly.

Now I'm not able to understand what is the issue related to PGM packets and why these packets are not captured at other side. How I can successfully replay these network traffic on the network using Destination Multi-cast Ip Address?

1
networkingudptcpreplaypgm-protocol

1 Answers

0
votes

The first "error" is actually a warning. We've seen a lot of pcap files with a snaplen of 9216 with packets which were truncated. You may want to load the file up in Wireshark and make sure it's ok.

Have you verified that in step #2 that auto-bridge mode is doing the right thing? Use tcpprep -S to check.

Is the "other side" directly connected, through a switch or VM?

Is the MAC address of the server on the "other side" already correct? If not, that's likely the issue.