UDP multicast client does not see UDP multicast traffic generated by tcpreplay - udp

Question

I have two programs:
server ... it generates UDP traffic on a chosen multicast
listener ... it prints UDP traffic on a chosen multicast
(it subscribes to a multicast and prints
whatever it receives).
When I run the server on one machine and listeners on some (other) machine(s), the listener sees UDP traffic and prints it correctly. So these programs should be in a good shape.
However, when I try to capture the traffic, on whatever machine, with tcpdump:
sudo tcpdump -i eth0 'dst 233.65.120.153' -w 0.pcap
and when I later try to replay it, on whatever machine, with tcpreplay:
sudo tcpreplay -i eth0 0.pcap
none of the listeners sees those captured packets:
09:38:40.975604 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 32)
172.27.6.176.53507 > 233.65.120.153.64968: [udp sum ok] UDP, length 4
0x0000: 4500 0020 0000 4000 0111 6527 ac1b 06b0 E.....#...e'....
0x0010: e941 7899 d103 fdc8 000c 579c 6162 6364 .Ax.......W.abcd
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
09:38:41.975709 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 32)
172.27.6.176.53507 > 233.65.120.153.64968: [udp sum ok] UDP, length 4
0x0000: 4500 0020 0000 4000 0111 6527 ac1b 06b0 E.....#...e'....
0x0010: e941 7899 d103 fdc8 000c 579c 6162 6364 .Ax.......W.abcd
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
09:38:42.975810 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto UDP (17), length 32)
172.27.6.176.53507 > 233.65.120.153.64968: [udp sum ok] UDP, length 4
0x0000: 4500 0020 0000 4000 0111 6527 ac1b 06b0 E.....#...e'....
0x0010: e941 7899 d103 fdc8 000c 579c 6162 6364 .Ax.......W.abcd
0x0020: 0000 0000 0000 0000 0000 0000 0000 ..............
Note that even though none of the listeners sees UDP multicast traffic, I am still able to see it, on whatever machine, with tcpdump:
sudo tcpdump -i eth0 'dst 233.65.120.153' -X
My question: What should I do (differently) if I want to tcpreplay the UDP multicast traffic I am creating so that I can see it on application level (e.g. my listener program), not only by tcpdump?
$ cat sender.c
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <time.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#define PORT 64968
#define GROUP "233.65.120.153"
main(int argc, char *argv[])
{
struct sockaddr_in addr;
int fd, cnt;
struct ip_mreq mreq;
char *message="abcd";
/* Create what looks like an ordinary UDP socket:
AF_INET ... IPv4
SOCK_DGRAM ... UDP
0 ... required constant
*/
if ((fd=socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("socket");
exit(1);
}
/* Set up destination address:
AF_INET ... IPv4
GROUP ... the IP-address of the multicast group
to which we want to multicast
PORT ... the UDP port that on which we want to multicast
*/
memset(&addr, 0, sizeof(addr));
addr.sin_family=AF_INET;
addr.sin_addr.s_addr=inet_addr(GROUP);
addr.sin_port=htons(PORT);
/* now just sendto() our destination! */
while (1) {
if (sendto(fd, message, strlen(message), 0, (struct sockaddr *) &addr, sizeof(addr)) < 0) {
perror("sendto");
exit(1);
}
sleep(1);
}
}
$ cat listener.c
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <time.h>
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
#define PORT 64968
#define GROUP "233.65.120.153"
#define MSGBUFSIZE 1000000
char msgbuf[MSGBUFSIZE];
main(int argc, char *argv[])
{
struct sockaddr_in addr;
int fd, nbytes,addrlen;
struct ip_mreq mreq;
u_int yes=1;
/* Create what looks like an ordinary UDP socket:
AF_INET ... IPv4
SOCK_DGRAM ... UDP
0 ... required constant
*/
if ((fd=socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
perror("socket");
exit(1);
}
/* Allow multiple sockets to use the same PORT number:
SOL_SOCKET ... manipulate properties of the socket API itself
SO_REUSEADDR ... Allow reuse of local addresses for bind
*/
if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes)) < 0) {
perror("Reusing ADDR failed");
exit(1);
}
/* set up destination address */
memset(&addr,0,sizeof(addr));
addr.sin_family=AF_INET;
addr.sin_addr.s_addr=htonl(INADDR_ANY); /* N.B.: differs from sender */
addr.sin_port=htons(PORT);
/* bind to receive address */
if (bind(fd,(struct sockaddr *) &addr,sizeof(addr)) < 0) {
perror("bind");
exit(1);
}
/* use setsockopt() to request that the kernel join a multicast group */
mreq.imr_multiaddr.s_addr=inet_addr(GROUP);
mreq.imr_interface.s_addr=htonl(INADDR_ANY);
if (setsockopt(fd,IPPROTO_IP,IP_ADD_MEMBERSHIP,&mreq,sizeof(mreq)) < 0) {
perror("setsockopt");
exit(1);
}
/* now just enter a read-print loop */
while (1) {
addrlen=sizeof(addr);
memset(msgbuf, 0, MSGBUFSIZE);
if ((nbytes=recvfrom(fd, msgbuf, MSGBUFSIZE,0,
(struct sockaddr *) &addr, &addrlen)) < 0) {
perror("recvfrom");
exit(1);
}
printf("Incoming message size = %d\n", nbytes);
int i;
for (i=0; i < nbytes; i++)
printf("%02x ", ((unsigned char) msgbuf[i]));
printf("\n");
}
}

Answer 1

We had the same problem. With tcpdump we saw the data; however, the multicast client/listener was not picking up the data. Then we realized that the Reverse Path Filter (rp_filter) was rejecting the packets.
After disabling the rp-filter, the client/listener application started picking up the packets. Use the below command to disable rp_filter:
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
In the above, replace 'eth0' with the interface receiving the multicast if other than eth0

Answer 2

To my knowledge, you can't do this on the same box ,tcpreplay bypasses the host's
routing table and sends traffic out the interface.
you have to start your listener on a different box. and make sure multicast is enabled. because by default, switch discards multicast traffic.

Answer 3

In my case I needed to adjust the pcap file by setting the correct destination MAC address. Also the checksum should be recalculated. And yes, 2 hosts are required for "tcpreplay". Without these I was fighting for a long time but only "tcpdump" showed the replayed stream, not my multicast listening app :(

Answer 4

This is just a theory, but it might be that the packets are discarded by the receiving side due to their checksums being wrong.
That could happen if the machine where you run tcpdump has IP or UDP checksum offloading enabled. That means the packages you capture locally haven't their checksums calculated yet, which the hardware does before sending them out. When you then tcpreplay those packets, the checksums are not calculated, as tcpreplay works on a lower level than the socket API you used to generate the packets.
In order to verify the correctness of the checksums (both those of the dump file as well as those of the packets spit out by the subsequent tcpreplay), tcpdump -v ... will warn you about wrong checksums. wireshark also colors wrongly checksummed frames differently (unless turned off in the wireshark settings).
Did you try to tcpdump the packets only on the sending host, or also on the receiving host? The latter would remove the checksum errors, if that is indeed your problem.

Answer 5

In Windows (I write it because in topic name you not specify that is not Windows) there is problem like this with different programs. But this program works fine Colasoft Packet Player. First time you should start it with administrative privileges.
OR (for all possible systems) you can try check this list.

Answer 6

Can I join the party?
Now, it is mentioned clearly on the FAQ page.
https://tcpreplay.appneta.com/wiki/faq.html#can-i-send-packets-on-the-same-computer-running-tcpreplay
Q: Can I send packets on the same computer running tcpreplay?
Generally speaking no. When tcpreplay sends packets, it injects them
between the TCP/IP stack of the system and the device driver of the
network card. The result is the TCP/IP stack system running tcpreplay
never sees the packets.
One suggestion that has been made is using something like VMWare,
Parallels or Xen. Running tcpreplay in the virtual machine (guest)
would allow packets to be seen by the host operating system.