3

I need to test an application which drops a user-specified percentage of packets. Right now, it will drop any packet type which I can easily verify by sending pings and observing the ICMP messages in Wireshark.

I want to enhance it so the user can specify that they only want to drop 20% of UDP packets for example, but I don't know how to send a controlled amount of UDP packets so as to test this. I'm only asking to send UDP for now. There are no constraints on transmit rate. I already have other traffic coming from OSPF hello messages and can also use ICMP traffic from pings to see that only the entered percentage of the specified protocol is dropped.

How can I use free tools to test UDP packet drops as-described above, using a Linux machine?

7
  • maybe it helps : sourceforge.net/projects/traffic
    – aseaudi
    Jan 8, 2014 at 19:22
  • maybe it helps: download.cnet.com/Network-Traffic-Generator-and-Monitor/…
    – aseaudi
    Jan 8, 2014 at 19:23
  • @THEDOCTOR, this question is so easy it's hard to believe you couldn't google to find the answer. We can let this question ride for now, but with so many different ways to do it, I'm a little concerned that it's just going to be a lightning-rod for everyone who wants: A) a few upvotes, or B) to mention their favorite tool. I added a post notice below. Jan 8, 2014 at 19:28
  • 1
    @aseaudi - Thanks, but those are both Windows applications while I specified that I am looking to do this on a Linux machine.
    – THE DOCTOR
    Jan 8, 2014 at 19:35
  • @MikePennington - Not looking for any upvotes and I did try to google for an answer, but couldn't find anything. Idk...maybe I'm just bad at searching if it really is that easy to find.
    – THE DOCTOR
    Jan 8, 2014 at 19:51

3 Answers 3

10

I would take a look at iperf. You should be able to use built in reporting in iperf to validate the amount of traffic dropped.

iperf is typically ran across the network between two systems. I have iperf3 installed on two CentOS machines, as you can see below, one is configured as the server and the other the client.

Install the iperf rpm, start the server first, and then start the client. Starting the iperf server is as simple as running the following command:

Machine #1

iperf3 -s

The -s option specifies to run iperf in server (receiver) mode. Initially (by default) the server will listen on 5201/tcp which will be used as a control channel, this port is configurable. Ensure your iptables (or equivalent) is configured to accommodate both the initial control channel and any subsequent udp flows.

Your client command and subsequent reporting after the transfer will look like this.

Machine #2

Machine #2 (this command essentially says "act as a client, connect to 192.168.2.202, use the udp protocol , send 1GB of data at a data rate of 100Mbps)

$ iperf3 -c 192.168.2.202 -u -n 1G -b 100M 

Connecting to host 192.168.2.202, port 5201

[  4] local 192.168.2.160 port 54356 connected to 192.168.2.202 port 5201
[ ID] Interval           Transfer     Bandwidth

[  4]   0.00-82.00  sec  1.00 GBytes   105 Mbits/sec
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-82.00  sec  1.00 GBytes   105 Mbits/sec  5.016 ms  12372/131072 (9.4%)
[  4] Sent 131072 datagrams

That's all you need to do with iperf

8

Using a search for "linux ethernet packet generator" gives me packeth as the first hit.

packeth Solution:

  • Has both a GUI and CLI version
  • Generates not only UDP, but many other protocols as well, including QinQ
  • Is packaged for RedHat as an rpm, or Debian package

netcat and tcpdump Solution:

If it was me, I would just do a quick-and-dirty ten second netcat test, because netcat is already installed in most linux distros... this is an example of sending a linux file (or in my example, /dev/urandom) via UDP...

First start tcpdump on both sides, and listen for a rare UDP port (use 65535/udp in this example). I'm using -s 1 to reduce the amount of work tcpdump has to do (which means it captures faster).

  • tcpdump -s 1 -ni eth0 udp and port 65535

Next, optionally start your receiver with a timed finish (backgrounding the netcat portion in a subshell so it won't block). This is not really necessary if you don't care about checksumming the received data.:

(nc -q 1 -u -l -p 65535 > /dev/null &); sleep 10; fuser -k 65535/udp;

Then, start your Transmitter ... in this case, I show it pushing the output of /dev/urandom to on udp/65535. Use a real file if you like...

(cat /dev/urandom | nc -u <DESTINATION_IP> 65535&); sleep 10; \
    fuser -n udp ,<DESTINATION_IP>,65535 -k

be sure you choose the timeout (I'm using sleep 10, above) to be long enough to sequence the shell commands and finish the network transfer. If you're transferring something other than /dev/urandom, be sure you sleep long enough to finish the file transfer.

When you're done, stop tcpdump on both sides. When it exits, you'll get packet counts from tcpdump:

[mpenning@tsunami ~]$ sudo tcpdump -s 1 -ni eth0 udp and port 65535
14:18:55.563674 [|ether]
14:18:55.563688 [|ether]

^C
2000 packets captured
2000 packets received by filter
0 packets dropped by kernel
[mpenning@tsunami ~]$

Do the math of sender_count - receiver_count, and that's your packet loss.

2

By far the best packet and traffic generator I have come across for Linux is PacketETH;

You can use it via CLI or via GUI. It is for generating Ethernet frames but you can also specify higher protocols such as IPv4/6, and TCP/UDP etc.

It's very powerful letting you customise pretty much all header options for protocols in layer 2, 3 and 4 (so Ethernet, IPv4/6, TCP/UDP) directly. You can send any higher layer protocol really though, not just the per-programmed ones as once you have created an Ethernet frame you can then write in the payload which of course could be the header and payload of any other higher layer protocol you like.

If you use Linux you should have it, almost know one seems to know about it and it's so powerful!

You also have features like saving the custom packet designs you create and re-loading them at a later date. Also you can and send "batches" of them which is what you want in either a burst of 1000 packets (for example) or at a constant rate of 2Mbps (also as an example).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.